[Bug target/21351] internal compiler error with sse
-- What|Removed |Added Component|c++ |target Keywords||ice-on-valid-code, ssemmx http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21351
[Bug libfortran/21324] #undef GFC_CLEAR_MEMORY causes testsuite failures
--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-05-03 06:52 --- Patch here: http://gcc.gnu.org/ml/fortran/2005-05/msg00016.html -- What|Removed |Added Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21324
[Bug fortran/19292] [meta-bug] g77 features lacking in gfortran
-- Bug 19292 depends on bug 20224, which changed state. Bug 20224 Summary: gfortran - flags error on strange, but correct f66 program http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20224 What|Old Value |New Value Status|NEW |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19292
[Bug fortran/20224] gfortran - flags error on strange, but correct f66 program
--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-05-03 07:04 --- Resolving as WONTFIX, as agreed. There realy isn't a good reason to support this. Thomas -- What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20224
[Bug tree-optimization/21292] gen-vect-11b.c and gen-vect-11c.c fail
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |bonzini at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-05-03 07:37:18 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21292
[Bug middle-end/21282] [4.1 Regression] Converting floor into lfloor built-in function
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-03 08:09 --- Subject: Bug 21282 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-05-03 08:08:46 Modified files: gcc: ChangeLog convert.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.dg: pr21282.c Log message: PR middle-end/21282 * convert.c (convert_to_integer): Convert ceil and floor in c99 mode only. testsuite: PR middle-end/21282 * gcc.dg/pr21282.c: New. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.8569r2=2.8570 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/convert.c.diff?cvsroot=gccr1=1.61r2=1.62 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.5432r2=1.5433 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/pr21282.c.diff?cvsroot=gccr1=NONEr2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21282
[Bug tree-optimization/21292] gen-vect-11b.c and gen-vect-11c.c fail
--- Additional Comments From bonzini at gcc dot gnu dot org 2005-05-03 08:14 --- The reason is that ia64 does not have any option to enable special SIMD instructions, so it can vectorize these tests using hardware 64-bit vectors. The two tests should be skipped on ia64, and actually even the others do not make much sense because they are complete dups of the tests in gcc.dg/vect. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21292
[Bug libfortran/21127] reshape of complex broken
--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-05-03 08:23 --- Patch here: http://gcc.gnu.org/ml/fortran/2005-04/msg00716.html -- What|Removed |Added Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21127
[Bug tree-optimization/21054] [4.1 Regression] ICE in ssa check for -ftree-vectorize -fprofile-generate
-- Bug 21054 depends on bug 20947, which changed state. Bug 20947 Summary: [4.1 Regression] ICE in check_loop_closed_ssa_use, at tree-ssa-loop-manip.c:394 with -ftree-vectorize http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20947 What|Old Value |New Value Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21054
[Bug tree-optimization/20947] [4.1 Regression] ICE in check_loop_closed_ssa_use, at tree-ssa-loop-manip.c:394 with -ftree-vectorize
--- Additional Comments From micis at gmx dot de 2005-05-03 08:24 --- Now it works for me too. Michael Cieslinski -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20947
[Bug c++/21352] New: ICE on valid code with passing template function type as template type
20549
* the exact version of GCC
gcc version 3.4.4 20050503 (prerelease)
* the system type
i686-pc-linux-gnu (rhel3)
* the options given when GCC was configured/built
../gcc/configure --prefix=/opt/gcc34-20050503 --enable-languages=c,c++
* the complete command line that triggers the bug;
/opt/gcc34-20050503/bin/g++ -c -o test.o test.cpp
* the compiler output (error messages, warnings, etc.)
test.cpp: In constructor `definitionScannerT::definition()':
test.cpp:25: internal compiler error: in resolve_overloaded_unification, at
cp/pt.c:9317
Please submit a full bug report,
with preprocessed source if appropriate.
preprocessed file (test.ii):
# 1 test.cpp
# 1 built-in
# 1 command line
# 1 test.cpp
struct coperator_stack
{
templateclass type
void push3()
{
}
};
struct helper {};
templateclass F
void bla(F f)
{
}
template typename ScannerT
struct definition
{
definition()
{
bla(coperator_stack::push3helper);
}
};
--
Summary: ICE on valid code with passing template function type as
template type
Product: gcc
Version: 3.4.4
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: weary at gamebox dot net
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=21352
[Bug c++/21352] ICE on valid code with passing template function type as template type
--- Additional Comments From weary at gamebox dot net 2005-05-03 08:31 --- also in 4.0.0 -- What|Removed |Added Known to fail||4.0.0 Known to work||3.3.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21352
[Bug libstdc++/21334] Lack of Posix compliant thread safety in std::basic_string
--- Additional Comments From jkanze at cheuvreux dot com 2005-05-03 08:34 --- Subject: Re: Lack of Posix compliant thread safety in std::basic_string | Isn't this a bug as opposed to enhancement? Enhancement | suggests that the behaviour is basically correct, but could be | improved. I could accept that. The behavior *is* conforme with your documentation, even if it isn't conforme with what Posix normally requires. -- James Kanze This message, including any attachments may contain confidential and privileged material; it is intended only for the person to whom it is addressed. Its contents do not constitute a commitment by Credit Agricole Cheuvreux except where provided for in a written agreement. Credit Agricole Cheuvreux assumes no liability or responsibility for the consequences arising out of a delay and/or loss in transit of this message, or for corruption or other error(s) arising in its transmission and for any misuse or fraudulent use which may be made thereof. If you are not the intended recipient, please contact us and abstain from any disclosure, use or dissemination. To the extent that this message contains research information and/or recommendations, these are provided on the same basis as Credit Agricole Cheuvreux's published research and the recipient must have regard to all disclosures and disclaimers contained therein. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21334
[Bug libstdc++/21334] Lack of Posix compliant thread safety in std::basic_string
--- Additional Comments From jkanze at cheuvreux dot com 2005-05-03 08:37 --- Subject: Re: Lack of Posix compliant thread safety in std::basic_string | Does the C++ standard mention multithreading and Posix | threads? ;) No, but the g++ installation procedures do. According to the installation procedured, with the options I gave on generation, the compiler supports the Posix thread model. Or are you suggesting that g++ should return to the pre-3.0 position that multithreaded programs don't exist, or aren't interesting to g++ users. -- James Kanze This message, including any attachments may contain confidential and privileged material; it is intended only for the person to whom it is addressed. Its contents do not constitute a commitment by Credit Agricole Cheuvreux except where provided for in a written agreement. Credit Agricole Cheuvreux assumes no liability or responsibility for the consequences arising out of a delay and/or loss in transit of this message, or for corruption or other error(s) arising in its transmission and for any misuse or fraudulent use which may be made thereof. If you are not the intended recipient, please contact us and abstain from any disclosure, use or dissemination. To the extent that this message contains research information and/or recommendations, these are provided on the same basis as Credit Agricole Cheuvreux's published research and the recipient must have regard to all disclosures and disclaimers contained therein. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21334
[Bug c++/21205] using-directive does not honor name selection via typedef
--- Additional Comments From boris at kolpackov dot net 2005-05-03 08:43 --- Not that I think you will change your mind, just for the record... 'S' was explicitly disambiguated in 'M' with 'typedef S1 S'. For that reason reference to 'S' within 'M' is not ambiguous. It seems logical that such explicit disambiguation should still be in effect in 'K'. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21205
[Bug c++/21353] New: rvalues should not be allowed to be default values for non const references in class functions.
works as expected on : gcc 2.95, freebsd/linux
does not work as expected on: gcc 3.4.2, freebsd/linux
//non-const references to temp values should be disallowed
--
//the code
enum X{ a, b, c };
class C
{
public:
void func( X ref = a ) //illegal - should not compile.
{ }
};
int main( )
{ }
//compile with gcc 2.95
$g++ test2.cpp
test2.cpp:7: invalid type `X' for default argument to `X '
//compile with gcc 3.4.2
$g++3 test2.cpp
$
this problem does not exist for functions in global scope.
--
Summary: rvalues should not be allowed to be default values for
non const references in class functions.
Product: gcc
Version: 3.4.2
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: s_siddharth_reddy at yahoo dot com
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21353
[Bug libstdc++/21334] Lack of Posix compliant thread safety in std::basic_string
--- Additional Comments From jkanze at cheuvreux dot com 2005-05-03 08:56 --- Subject: Re: Lack of Posix compliant thread safety in std::basic_string | I am sending this to the g++ bug list on the recommendation of | Gabriel Dos Reis. From what little I've read in the g++ | documentation, I'm not convinced that the authors of the g++ | library intend for it to be supported, although Posix would seem | to require it. | Firstly, POSIX says nothing about C++ thus my confusion starts here. The statement I quoted from the Posix standard is language neutral. A priori, it applies to all languages. | Secondly, it is clear that your bug report is hypothetical. The | library maintainers do not typically deal in hypotheticals. I guess it is really a question of whether you want quality or not. In general, all code is supposed incorrect until proven otherwise -- in the case of threading issues, this is particularly important, because of the random factors involved. In this particular case, there is only a very, very small window of time in which the error can occur. I could add a lot of extra code, which would only obfuscate the real problem, but would increase the chances that the error occurs. I could probably, experimentally, add just the right amount so that the error occurred more or less regularly (say one execution in ten) on my machine. Unless your machine had exactly the same configuration (processor, clock speed, background processes, etc.), the error would probably not trigger there. | For the record, the statement in Posix is: Applications shall | ensure that access to any memory location by more than one | thread of control (threads or processes) is restricted such that | no thread of control can read or modify a memory location while | another thread of control may be modifying it. The obvious | extension to C++ is that of replacing memory location with | object; at the very least, of course, one can only require | something of memory locations which the user sees, directly or | indirectly. | OK. | The statement in the libstdc++-v3 FAQ (question | 5.6) is: All library objects are safe to use in a multithreaded | program as long as each thread carefully locks out access by any | other thread while it uses any object visible to another thread, | i.e., treat library objects like any other shared resource. In | general, this requirement includes both read and write access to | objects; unless otherwise documented as safe, do not assume that | two threads may access a shared standard library object at the | same time. | OK, I seem to recall editing that statement at one point... | A considerably weaker guarantee than what one | normally expects under Posix. (Note that the clause like any | other shared resource is simply false for those of us used to | the Posix model. If I replace std::string with char[] in my | code below, the behavior is perfectly defined under Posix.) | No, confusion. We are guaranteeing that if you lock the visible | accesses to global or otherwise shared objects, that no POSIX | threading rule will be violated within our own library code. Well, there's certainly some confusion, because Posix says one thing, and your documentation says another. When you say treat library objects like any other shared resources', you are contradicting yourself for a system using the Posix model. In the case of string, of course, the obvious other' system resource to compare it with is char[]. If you replace std::string with char[], in my example program, the code is well defined and guaranteed to work under Posix. | We are | saying that we guarantee that any internal shared objects (which may | not be visible to the user, thus not lockable by the user) will be | correctly handled per POSIX threading rules. I know what you are guaranteeing (in the statement above). It's because of this statement (or a similar one elsewhere in the documentation) that I hadn't sent in a bug report, but that I did take the bother of warning people in various news groups that in g++, std::string did not behave as one would normally expect. You can use it, but you have to take additional precautions that Posix says shouldn't be necessary, and that experienced Posix users don't expect to need. An implementation, of course, is free to decide what it wants to guarantee, and what it doesn't. If it is decided, however, that the Posix guarantees do not extend to the library, then it is important to document this fact; i.e. to indicate somewhere that it cannot be missed that configuring the compiler to support pthreads does NOT mean what it seems to mean. -- James Kanze This message, including any attachments may contain confidential and privileged material; it is intended only for the person to whom it is addressed. Its contents do not constitute a commitment by Credit Agricole Cheuvreux except where provided for in a written agreement. Credit Agricole Cheuvreux assumes no liability or
[Bug libfortran/21354] New: Rank 7 not handled correctly
There are numerous places in the library where rank 7 arrays are not handled correctly. This affects, for example, in_pack: $ cat re.f90 program main real, dimension (2,2,2,2,2,2,2):: a a = 1.0 call foo(a(2:1:-1,:,:,:,:,:,:)) end program main subroutine foo(a) real, dimension (2,2,2,2,2,2,2):: a print *,a end subroutine foo $ gfortran re.f90 $ ./a.out Segmentation fault $ gfortran -v Using built-in specs. Target: ia64-unknown-linux-gnu Configured with: ../gcc-4.1-20050501/configure --prefix=/home/zfkts --enable- languages=c,f95 Thread model: posix gcc version 4.1.0 20050501 (experimental) plus a whole lot of other intrinsics. The solution is fairly simple: All intermediate array declarations in the library like index_type rstride[GFC_MAX_DIMENSIONS - 1]; need to be changed to index_type rstride[GFC_MAX_DIMENSIONS]; -- Summary: Rank 7 not handled correctly Product: gcc Version: 4.1.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P2 Component: libfortran 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=21354
[Bug ada/21355] New: [3.4 regression] ada bootstrap comparision failure
seen with CVS 20050502, last version that built sucessfully was CVS 20050413. reproducible on i486-linux and x86_64-linux. Bootstrap comparison failure! ada/b_gnatb.o differs make[3]: *** [gnucompare-lean] Error 1 -- Summary: [3.4 regression] ada bootstrap comparision failure Product: gcc Version: 3.4.4 Status: UNCONFIRMED Severity: normal Priority: P2 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: debian-gcc at lists dot debian dot org CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21355
[Bug libstdc++/21334] Lack of Posix compliant thread safety in std::basic_string
--- Additional Comments From jkanze at cheuvreux dot com 2005-05-03 09:09 --- Subject: Re: Lack of Posix compliant thread safety in std::basic_string | Whereas I'm all for providing alternate memory management | policies (we are very close to that in the v7-branch and I | promise further progress during the next months) I fail to | properly appreciate the actual details of this issue: which | applications are actually penalized, which are the alternatives, | something more concrete, in other terms, that a vague reference | to those position papers that we all know, in other terms ;) | (and one of those I'd like to discuss in detail...) Maybe James | can help here. I'm not sure what sort of help you are looking for. I thought that I very clearly pointed out the problem, and the point in the code where it occured. In typicaly code, the problem occurs mainly with configuration variables; they are declared non-const, because they have to be set on start up, either from the command line, or from a configuration file, and then used as if they were const. According to Posix, I should be able to access such variables without additional, user defined synchronization. Note that the problem can be very, very subtle, and that most of the time, the program will work despite the problem -- this is one of the most pernicious cases of undefined behavior. | In practice, we could, for instance, *within the | current ABI*, provide a switch to disable completely reference | counting, would that be appreciated? It would help. But an implementation designed with reference counting in mind is likely to be rather slow when reference counting is turned off. IMHO, correct and slow is better than the current situation, but not all compiler users agree. | I can implement this very | quickly but I'd like to have some evidence that a non-trivial | number of users would appreciate that short-term solution. That | would be indeed, a short term solution, because a library | relying purely on a non-refcounted string has subtle issues with | memory allocation during exceptions, that definitely we don't | want in a long term solution: if nobody has got a better idea, | I'm afraid we have to implement also a separate ref-counted | mini-string for usage in exceptions. Most other implementations I'm aware of don't use std::string in exceptions. That would seem to be the best solution. Other than that, there is no perfect solution with regards to exceptions. If an exception requires resources, and they aren't there, there's going to be a problem. What happens if you can't allocate the memory for the exception itself? -- James Kanze This message, including any attachments may contain confidential and privileged material; it is intended only for the person to whom it is addressed. Its contents do not constitute a commitment by Credit Agricole Cheuvreux except where provided for in a written agreement. Credit Agricole Cheuvreux assumes no liability or responsibility for the consequences arising out of a delay and/or loss in transit of this message, or for corruption or other error(s) arising in its transmission and for any misuse or fraudulent use which may be made thereof. If you are not the intended recipient, please contact us and abstain from any disclosure, use or dissemination. To the extent that this message contains research information and/or recommendations, these are provided on the same basis as Credit Agricole Cheuvreux's published research and the recipient must have regard to all disclosures and disclaimers contained therein. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21334
[Bug libstdc++/21334] Lack of Posix compliant thread safety in std::basic_string
--- Additional Comments From pcarlini at suse dot de 2005-05-03 09:29 --- I'm not sure what sort of help you are looking for. I thought that I very clearly pointed out the problem, and the point in the code where it occured. Ok, my message was not clear. I'm looking for help about the *performance* issue, not the correctness issue. To your best knowledge all those users that avoid v3 basic_string for MT applications do that for performance or for correctness (wrt the Posix issue that you are pointing out in detail)?? Reading those papers that I mentioned before (+ another one on C/C++ Users Journal which exactly touches *your* issue) it's *not* at all clear that the latter is the main issue, in the general understanding. It would help. But an implementation designed with reference counting in mind is likely to be rather slow when reference counting is turned off. IMHO, correct and slow is better than the current situation, but not all compiler users agree. Indeed. Of course I'm talking about a *switch* (off by default) But, about the correctness point... Most other implementations I'm aware of don't use std::string in exceptions. That would seem to be the best solution. Ok, but I don't think we can also change that in the short term and not affecting the ABI, we are definitely going to do that in v7-branch and I would appreciate if you could advise about the best solution among all those proposed (see the thread). Returning to our issue, however, do you still believe that a switch turning off RC would be useful if we don't change the treatment of exceptions? I don't know, maybe we can have something simple for that within the present ABI, but I cannot make promises and want to have an idea of the amount of work. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21334
[Bug target/19933] Problem with define of HUGE_VAL in math_c99.
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-05-03
09:48 ---
I'm not sure what is best done with the signbit definition (maybe nothing if
it will never call a library function at present, even though it isn't
properly type-generic);
We can discriminate using sizeof, like in glibc.
but the others can be done, e.g.
#define isfinite(x) __extension__ ({ __typeof (x) __x = (x); __builtin_expect
(!isnan(__x - __x), 1); })
This works fine for big numbers, but are there similar tricks to distinguish
denormals from normals? If no, we'll have to resort to FLT_MIN and the like or
to bitwise-testing the exponent against 0.
I'm going to attach a first version of math_c99.h.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19933
[Bug libstdc++/21131] Mismatch in comments for m4 config macros in libstdc++
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-03 09:50 --- Subject: Bug 21131 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-3_3-branch Changes by: [EMAIL PROTECTED] 2005-05-03 09:49:47 Modified files: libstdc++-v3 : ChangeLog acinclude.m4 Log message: 2005-05-03 Jones Desougi [EMAIL PROTECTED] PR libstdc++/21131 * acinclude.m4: Fix comments. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-3_3-branchr1=1.1464.2.197r2=1.1464.2.198 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/acinclude.m4.diff?cvsroot=gcconly_with_tag=gcc-3_3-branchr1=1.223.2.11r2=1.223.2.12 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21131
[Bug libstdc++/21131] Mismatch in comments for m4 config macros in libstdc++
--- Additional Comments From gdr at gcc dot gnu dot org 2005-05-03 10:01 --- Applied 3.3.x patch too. -- What|Removed |Added Target Milestone|3.4.4 |3.3.6 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21131
[Bug libstdc++/21131] Mismatch in comments for m4 config macros in libstdc++
--- Additional Comments From pcarlini at suse dot de 2005-05-03 10:15 --- ... remember to regenerate ;) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21131
[Bug libstdc++/21334] Lack of Posix compliant thread safety in std::basic_string
--- Additional Comments From pcarlini at suse dot de 2005-05-03 10:39 --- In exceptions, I'm tempted to use something very simple, a fixed-size buffer, as in STLPort, but that is the typical change affecting the ABI :( -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21334
[Bug target/19933] Problem with define of HUGE_VAL in math_c99.
--- Additional Comments From joseph at codesourcery dot com 2005-05-03 10:54 --- Subject: Re: Problem with define of HUGE_VAL in math_c99. On Tue, 3 May 2005, ebotcazou at gcc dot gnu dot org wrote: This works fine for big numbers, but are there similar tricks to distinguish denormals from normals? If no, we'll have to resort to FLT_MIN and the like or to bitwise-testing the exponent against 0. Use __FLT_MIN__ etc. since float.h may not be included. For a good fix we'll want to add built-in functions compatible with the Solaris header and remove the relevant fixes, and those would test the bits of the representation appropriately, but for now I think __FLT_MIN__ is the right approach and the fixes could more suitably go on 4.0 branch than new built-in functions. We have a functional __builtin_isnan, there is no need to fix that particular definition. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19933
[Bug libstdc++/21334] Lack of Posix compliant thread safety in std::basic_string
--- Additional Comments From jkanze at cheuvreux dot com 2005-05-03 10:59 --- Subject: Re: Lack of Posix compliant thread safety in std::basic_string | I'm not sure what sort of help you are looking for. I thought | that I very clearly pointed out the problem, and the point in | the code where it occured. | Ok, my message was not clear. I'm looking for help about the | *performance* issue, not the correctness issue. To your best | knowledge all those users that avoid v3 basic_string for MT | applications do that for performance or for correctness (wrt | the Posix issue that you are pointing out in detail)?? To the best of my knowledge, not very many people avoid basic_string. Most people aren't that aware of threading issues to begin with, and most people just use whatever is there, and suppose that it meets whatever standards are usual for thread-safety on the platform in question. I only started being more wary myself because on two occasions, I've had to fix programs which didn't work, because they used the basic_string which came with 2.95.2 -- it just didn't occur to the authors to ask the question whether the library gave the Posix guarantees. The situation with the current library is simple: there is a specific sequence of events which will cause it to use deleted memory, double delete, etc. For that to occur, one thread must access the same object via [], at(), begin() or end(), a second thread must copy the object, and the second thread must interrupt the first thread between the test whether the object is shared, and the moment it is marked as leaked. On a typical machine, that last condition will only last a couple of machine instructions, less than a microsecond. Which means that most of the time, even if the code is incorrect, it will seem to work. And every once in a blue moon, the user will get an unexplicable crash, that the developers cannot duplicate. The problem can be avoided. The easiest (and surest) way is by synchronizing manually; only accessing the global objects to copy them (using the copy constructor) should work as well. (As soon as the representation is shared, the code works. At least in practice on single processor machines; there are no memory barriers around the non-modifying reads, nor around the write of -1 to mark the representation as leaked, which means that some updates may not be correctly seen by threads running on a different processor. Only using copies still works, however; the thread which makes the copy will at least see its update, which results in a reference count greater than 0, which is all that is needed to trigger the deep copy before leaking. Still, it's pretty shaky, and I would have expected anyone familiar with thread safety issues to have ensured that the normal memory barriers were present.) | Reading | those papers that I mentioned before (+ another one on C/C++ | Users Journal which exactly touches *your* issue) it's *not* | at all clear that the latter is the main issue, in the general | understanding. I'm not too sure which papers you are referring to, even after Herb Sutter's name was mentionned. I do know that the one article I have read by Herb which concerned thread safety was full of errors, and resulted in a long discussion in comp.lang.c++.moderated. | It would help. But an implementation designed with reference | counting in mind is likely to be rather slow when reference | counting is turned off. IMHO, correct and slow is better than | the current situation, but not all compiler users agree. | Indeed. Of course I'm talking about a *switch* (off by default) | But, about the correctness point... | Most other implementations I'm aware of don't use std::string in | exceptions. That would seem to be the best solution. | Ok, but I don't think we can also change that in the short term | and not affecting the ABI, we are definitely going to do that in | v7-branch and I would appreciate if you could advise about the | best solution among all those proposed (see the thread). | Returning to our issue, however, do you still believe that a | switch turning off RC would be useful if we don't change the | treatment of exceptions? I don't know, maybe we can have | something simple for that within the present ABI, but I cannot | make promises and want to have an idea of the amount of work. I'm not sure. As I said, the biggest part of the problem is that people aren't aware of the problem. When it comes down to it, it's not nice, the the necessary work-arounds exist. If there is a new implementation in the pipeline which doesn't have the problem, then I'd probably settle for a couple of prominent warnings, in bold face, in the documentation. Even though users who actually even open the documentation seem in a minority, I'd say that the most important thing is to realize what the situation is, and document it. Thus, for example, in the statement from your FAQ that I quoted, you don't say like any
[Bug libstdc++/21334] Lack of Posix compliant thread safety in std::basic_string
--- Additional Comments From pcarlini at suse dot de 2005-05-03 11:14 --- Hi James, and thanks for your explanations. Indeed, maybe better concentrating on the v7-branch + documentation updates: as I told you already the framework is already there and I will add very soon a different policy for not-refcounted string + short string optimization. Remains open the exceptions issue but after all, now that I studied some materil, seems manageable. But I cannot really reply in detail to your last message, now, just some pointers: I'm not too sure which papers you are referring to, even after Herb Sutter's name was mentionned. Simply the series reprinted in More exceptional C++, in particular appendixes A and B. I do know that the one article I have read by Herb which concerned thread safety was full of errors, and resulted in a long discussion in comp.lang.c++.moderated. Ah, yes, thanks. I read part of that thread, but have to re-read it: in any case, will be not terribly useful for the work ahead. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21334
[Bug target/19933] Problem with define of HUGE_VAL in math_c99.
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-05-03 11:35 --- Use __FLT_MIN__ etc. since float.h may not be included. Of course. For a good fix we'll want to add built-in functions compatible with the Solaris header and remove the relevant fixes, and those would test the bits of the representation appropriately, but for now I think __FLT_MIN__ is the right approach and the fixes could more suitably go on 4.0 branch than new built-in functions. Agreed. I'll open an enhancement PR for the missing builtins. We have a functional __builtin_isnan, there is no need to fix that particular definition. Right, but it is type-dependent so I guess we have to play the sizeof game. I'm going to attach a revised version. Does it look OK to you? If so, I'll write tests and run them on SPARC (I don't have access to i386-pc-solaris2.10) before translating it into a fixinclude patch. Note that I'd like to have a fix for the 3.4 branch too, and we have neither __builtin_isnan nor __builtin_signbit on that branch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19933
[Bug middle-end/21356] New: Dominance error after aggressive dead code elimination (cd_dce)
I have internal compiler error for the following c code:
int a;
void* p;
void foo (void)
{
switch (a)
{
a0: case 0: p = a1;
a1: case 1: p = a2;
a2: default: p = a1;
}
goto *p;
}
Command line:
gcc -c -O2 1.c
Output:
1.c: In function 'foo':
1.c:5: error: dominator of 1 should be 2, not 0
1.c:5: internal compiler error: in verify_dominators, at dominance.c:875
...
--
Summary: Dominance error after aggressive dead code elimination
(cd_dce)
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: loki at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: i686-pc-linux-gnu-gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21356
[Bug libstdc++/21209] signed integer overflow in num_get::_M_extract_int
--- Additional Comments From pcarlini at suse dot de 2005-05-03 12:03 --- Fixed for 4.0.1. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21209
[Bug libstdc++/21209] signed integer overflow in num_get::_M_extract_int
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-03 12:12 --- Subject: Bug 21209 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-05-03 12:02:14 Modified files: libstdc++-v3 : ChangeLog libstdc++-v3/include/bits: locale_facets.tcc Added files: libstdc++-v3/testsuite/22_locale/num_get/get/char: 16.cc libstdc++-v3/testsuite/22_locale/num_get/get/wchar_t: 16.cc Log message: 2005-05-03 Paolo Carlini [EMAIL PROTECTED] PR libstdc++/21209 * include/bits/locale_facets.tcc (_M_extract_int): Avoid signed integer overflow, always use a suited unsigned type in the main parsing loop. (struct __to_unsigned_type): New. * testsuite/22_locale/num_get/get/char/16.cc: New. * testsuite/22_locale/num_get/get/wchar_t/16.cc: Likewise. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.2917.2.37r2=1.2917.2.38 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/include/bits/locale_facets.tcc.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.211.12.2r2=1.211.12.3 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/22_locale/num_get/get/char/16.cc.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=NONEr2=1.1.4.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/22_locale/num_get/get/wchar_t/16.cc.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=NONEr2=1.1.4.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21209
[Bug bootstrap/21355] [3.4 regression] ada bootstrap comparision failure
--- Additional Comments From debian-gcc at lists dot debian dot org
2005-05-03 12:30 ---
on powerpc-linux, the build fails earlier:
stage2/xgcc -Bstage2/ -B/usr/powerpc-linux/bin/ -c -O2 -DIN_GCC -W -Wall
-Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wno-error
-DHAVE_CONFIG_H-I. -Iada -I../../src/gcc -I../../src/gcc/ada
-I../../src/gcc/../include ada/b_gnatb.c -o ada/b_gnatb.o
ada/b_gnatb.c:64: error: missing terminating character
ada/b_gnatb.c:65:1: invalid suffix x on integer constant
ada/b_gnatb.c:65: error: missing terminating character
ada/b_gnatb.c:66: error: parse error before char
ada/b_gnatb.c: In function `main':
ada/b_gnatb.c:229: error: `__gnat_ada_main_program_name' undeclared (first use
in this function)
ada/b_gnatb.c:229: error: (Each undeclared identifier is reported only once
ada/b_gnatb.c:229: error: for each function it appears in.)
make[4]: *** [ada/b_gnatb.o] Error 1
comparing the files from the builds:
$ diff -u ./build/gcc/ada/b_gnatb.c ./build/gcc/stage2/ada/b_gnatb.c
--- ./build/gcc/ada/b_gnatb.c 2005-05-03 06:39:54.224491344 -0500
+++ ./build/gcc/stage2/ada/b_gnatb.c2005-05-03 05:56:32.313429600 -0500
@@ -61,8 +61,7 @@
extern int gnat_exit_status;
-char __gnat_version[] = GNAT Version:
-0x;
+char __gnat_version[] = GNAT Version: S\u\u\u;
char __gnat_ada_main_program_name[] = _ada_gnatbind;
void adafinal () {
system__standard_library__adafinal ();
the gnatbind.ali files do not differ.
setting the component to bootstrap, no ada files were modified in the mentioned
time frame. keeping the severity, hmm, but it fails on a branch where it worked
before.
--
What|Removed |Added
Component|ada |bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21355
[Bug target/19933] Problem with define of HUGE_VAL in math_c99.
--- Additional Comments From joseph at codesourcery dot com 2005-05-03 12:59 --- Subject: Re: Problem with define of HUGE_VAL in math_c99. On Tue, 3 May 2005, ebotcazou at gcc dot gnu dot org wrote: We have a functional __builtin_isnan, there is no need to fix that particular definition. Right, but it is type-dependent so I guess we have to play the sizeof game. __builtin_isnan is type-generic and functionally so, unlike __builtin_signbit which isn't although it should be and __builtin_isinf which tries to be type-generic and is broken in doing so (bug 20558). The __builtin_isnanf and __builtin_isnanl functions can be ignored. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19933
[Bug target/21297] [4.0/4.1 Regression] buf[i+i]=0 stores buf[i] when -O2
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-03 13:01 --- Subject: Bug 21297 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-05-03 12:58:13 Modified files: gcc: ChangeLog gcc/config/i386: i386.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.c-torture/execute: 20050502-2.c Log message: PR target/21297 * config/i386/i386.c (legitimize_address): When canonicalizing ASHIFT into MULT, multiply by 1 shift_count instead of 1 log2 (shift_count). * gcc.c-torture/execute/20050502-2.c: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.8572r2=2.8573 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/i386/i386.c.diff?cvsroot=gccr1=1.816r2=1.817 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.5433r2=1.5434 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/execute/20050502-2.c.diff?cvsroot=gccr1=NONEr2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21297
[Bug c/21357] New: Erroneous warning: ... may be used uninitialized in this function
Output of gcc -v:
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.0.0/configure --prefix=/home/williamg/local/x86_64-40
--enable-__cxa_atexit --enable-languages=c,c++
Thread model: posix
gcc version 4.0.0
Command line:
~/local/x86_64-40/bin/gcc -O1 -Wall -Werror -c 3.c -o 3.o
Output:
cc1: warnings being treated as errors
3.c: In function ‘main’:
3.c:6: warning: ‘initialised_when_a_is_non_zero’ may be used uninitialized
in
this function
Preprocessed source:
# 1 3.c
# 1 built-in
# 1 command line
# 1 3.c
extern int g (int);
int main () {
const int a = g (0);
int initialised_when_a_is_non_zero;
if (a)
initialised_when_a_is_non_zero = 10;
g (1);
if (a)
g (initialised_when_a_is_non_zero);
return 0;
}
It's clearly impossible that we use initialised_when_a_is_non_zero unless it
has been initialised.
The warning does not appear with -O0.
Removing the line g (1); also makes the warning disappear.
--
Summary: Erroneous warning: ... may be used uninitialized in
this function
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: william at gallaf dot net
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21357
[Bug rtl-optimization/21330] [4.0/4.1 Regression] ICE in compare_and_jump_seq, at loop-unswitch.c:120
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-03 13:10 --- Subject: Bug 21330 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-05-03 13:09:54 Modified files: gcc: ChangeLog loop-unswitch.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.c-torture/execute: 20050502-1.c Log message: PR rtl-optimization/21330 * loop-unswitch.c (may_unswitch_on): Set *cinsn only when returning non-NULL. (unswitch_single_loop): Clear cinsn when retrying. * gcc.c-torture/execute/20050502-1.c: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.8573r2=2.8574 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/loop-unswitch.c.diff?cvsroot=gccr1=1.29r2=1.30 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.5434r2=1.5435 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/execute/20050502-1.c.diff?cvsroot=gccr1=NONEr2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21330
[Bug c/21358] New: Erroneous warning: ... may be used uninitialized in this function
Output of gcc -v:
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.0.0/configure --prefix=/home/williamg/local/x86_64-40
--enable-__cxa_atexit --enable-languages=c,c++
Thread model: posix
gcc version 4.0.0
Command line:
~/local/x86_64-40/bin/gcc -O1 -Wall -Werror -c 3.c -o 3.o
Output:
cc1: warnings being treated as errors
3.c: In function ‘main’:
3.c:6: warning: ‘initialised_when_a_is_non_zero’ may be used uninitialized
in
this function
Preprocessed source:
# 1 3.c
# 1 built-in
# 1 command line
# 1 3.c
extern int g (int);
int main () {
const int a = g (0);
int initialised_when_a_is_non_zero;
if (a)
initialised_when_a_is_non_zero = 10;
g (1);
if (a)
g (initialised_when_a_is_non_zero);
return 0;
}
It's clearly impossible that we use initialised_when_a_is_non_zero unless it
has been initialised.
The warning does not appear with -O0.
Removing the line g (1); also makes the warning disappear.
--
Summary: Erroneous warning: ... may be used uninitialized in
this function
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: william at gallaf dot net
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21358
[Bug java/18399] [4.0/4.1 Regression] Class initialization optimization does not work with the inliner
--- Additional Comments From aph at gcc dot gnu dot org 2005-05-03 13:12 --- This bug is obsoleted by the fix for PR java/19285. -- What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18399
[Bug java/17574] [meta-bug] gcj and libgcj 4.0 tracking PR
-- Bug 17574 depends on bug 18399, which changed state. Bug 18399 Summary: [4.0/4.1 Regression] Class initialization optimization does not work with the inliner http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18399 What|Old Value |New Value Status|NEW |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17574
[Bug c/21358] Erroneous warning: ... may be used uninitialized in this function
--- Additional Comments From william at gallaf dot net 2005-05-03 13:32 --- Browser hung for 5 minutes after first submit without showing a bug submitted page, so I tried again ... apologies for noise. *** This bug has been marked as a duplicate of 21357 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21358
[Bug c/21357] Erroneous warning: ... may be used uninitialized in this function
--- Additional Comments From william at gallaf dot net 2005-05-03 13:32 --- *** Bug 21358 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21357
[Bug java/12911] Class initialization optimization pessimization
--- Additional Comments From aph at gcc dot gnu dot org 2005-05-03 13:34 --- I'm tempted to change this to WONTFIX. The patch for PR java/19285 party fixes this for indirect dispatch: in A.foo2(), the field B.bar is initialized by a call to _Jv_ResolvePoolEntry, and this is only called once, the first time A.foo2() is invoked. Granted, this only applies to the indirect dispatch (a.k.a. the new ABI) case. However, optimizing known incorrect behaviour doesn't seem like a good use of anyone's time. Because of the binary compatibility rules we can't assume that B.bar will always be a field of B; it might be a field of one of B's interfaces. Initializing B won't initialize its interfaces, so this code will fail. -- What|Removed |Added Status|NEW |SUSPENDED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12911
[Bug target/21314] C++ size and performance regression with -Os
-- What|Removed |Added CC||ivan at yosifov dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21314
[Bug c/21357] Erroneous warning: ... may be used uninitialized in this function
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-03 13:43 --- This is known and a long standing bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21357
[Bug SWING/20804] JFrames not using insets to calculate size.
--- Additional Comments From kho at redhat dot com 2005-05-03 14:25 --- Fixed in cvs. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20804
[Bug target/19933] Problem with define of HUGE_VAL in math_c99.
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-05-03 14:39 --- __builtin_isnan is type-generic and functionally so, unlike __builtin_signbit which isn't although it should be and __builtin_isinf which tries to be type-generic and is broken in doing so (bug 20558). 2 more questions: 1. Can we work around bug 20558 by using the sizeof trick for isinf? 2. Can we use __builtin_finite for isfinite? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19933
[Bug rtl-optimization/21239] [4.0/4.1 Regression] Illegal elimination of SSE2 load/store using xmm intrinsics
--- Additional Comments From jakub at gcc dot gnu dot org 2005-05-03 14:42 --- Yeah, a bug in combine_simplify_rtx. I have a patch that fixes this, but while working on a testcase I encountered other bug as well, so am looking into that too. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2005-04-27 00:00:41 |2005-05-03 14:42:12 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21239
[Bug other/21350] configure reports only a warning when bison is not installed
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-03 14:45 --- Are you building from the source tarball or from CVS? If from the source tarball, you don't need bison which is why it is just a warning. Otherwise this is a bug in the release process if bison is now required (and a regression). What is the current error you are getting building GCC? -- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21350
[Bug middle-end/21282] [4.1 Regression] Converting floor into lfloor built-in function
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-03 14:51 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21282
[Bug fortran/21359] New: gfortran internal error
-- Summary: gfortran internal error Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: critical Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: matt at mail dot bettencourt dot info CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21359
[Bug c++/21352] [3.4/4.0/4.1 Regression] ICE on valid code with passing template function type as template type
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-03
15:00 ---
Confirmed, reduced testcase:
struct coperator_stack
{
templateclass type
void push3();
};
templateclass F
void bla(F f);
template typename ScannerT
void f()
{
bla(coperator_stack::push3);
}
Related to PR 20549.
--
What|Removed |Added
BugsThisDependsOn||20549
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Keywords||ice-on-valid-code
Known to fail|4.0.0 |4.0.0 3.4.0 4.1.0
Last reconfirmed|-00-00 00:00:00 |2005-05-03 15:00:07
date||
Summary|ICE on valid code with |[3.4/4.0/4.1 Regression] ICE
|passing template function |on valid code with passing
|type as template type |template function type as
||template type
Target Milestone|--- |3.4.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21352
[Bug fortran/21359] gfortran internal error
-- What|Removed |Added Severity|critical|normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21359
[Bug fortran/21359] gfortran internal error
--- Additional Comments From matt at mail dot bettencourt dot info 2005-05-03 15:03 --- Created an attachment (id=8805) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8805action=view) code which causes compiler error -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21359
[Bug fortran/21359] gfortran internal error
--- Additional Comments From matt at mail dot bettencourt dot info 2005-05-03 15:04 --- mail.bettencourt.info gfortran -c part.f90 part.f90: In function 'updateposition': part.f90:168: internal compiler error: in gfc_conv_ss_descriptor, at fortran/trans-array.c:1264 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. mail.bettencourt.info gfortran -v -c part.f90 Reading specs from /usr/lib/gcc/i386-redhat-linux/4.0.0/specs Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --with-gxx-include-dir=/usr/include/c++/3.4.2 --enable-languages=c,c++,f95 --disable-libgcj --host=i386-redhat-linux Thread model: posix gcc version 4.0.0 20041019 (Red Hat 4.0.0-0.8) /usr/libexec/gcc/i386-redhat-linux/4.0.0/f951 part.f90 -quiet -dumpbase part.f90 -auxbase part -version -o /tmp/ccc7k0qh.s GNU F95 version 4.0.0 20041019 (Red Hat 4.0.0-0.8) (i386-redhat-linux) compiled by GNU C version 4.0.0 20041019 (Red Hat 4.0.0-0.8). GGC heuristics: --param ggc-min-expand=99 --param ggc-min-heapsize=129494 part.f90: In function 'updateposition': part.f90:168: internal compiler error: in gfc_conv_ss_descriptor, at fortran/trans-array.c:1264 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. mail.bettencourt.info uname -a Linux mail.bettencourt.info 2.6.10-1.770_14.rhfc3.at #1 Fri Mar 4 11:34:31 EST 2005 i686 athlon i386 GNU/Linux -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21359
[Bug c++/21353] [3.4/4.0/4.1 Regression] rvalues should not be allowed to be default values for non const references in class functions.
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-03 15:04 --- The problem is that we are checking too late. Confirmed, a regression from 3.3.3. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||accepts-invalid Known to fail||4.0.0 4.1.0 3.4.0 Known to work||3.3.3 Last reconfirmed|-00-00 00:00:00 |2005-05-03 15:04:22 date|| Summary|rvalues should not be |[3.4/4.0/4.1 Regression] |allowed to be default values|rvalues should not be |for non const references in |allowed to be default values |class functions.|for non const references in ||class functions. Target Milestone|--- |3.4.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21353
[Bug c/21360] New: wrong result of 'if' statement with comparing of floating point with gcc.
Following code produces wrong results:
#include stdio.h
float f = -1.0f ;
int main( void )
{
if ( (unsigned int)f != (unsigned int)-1.0f ) {
printf( %-12s %04d:NG...[%u]---[%u]\n,
__FILE__, __LINE__, (unsigned int)-1.0f, (unsigned
int)f ) ;
} else {
printf( [%u]---[%u] :OK\n, (unsigned int)-1.0f, (unsigned
int)f ) ;
}
return( 0 ) ;
}
[EMAIL PROTECTED] tmp]$
/home/dinar/work/gcc-builds/gnu/gcc-i686-pc-linux-gnu/bin/gcc
sample.c -o sample
[EMAIL PROTECTED] tmp]$ ./sample
sample.c 0010:NG...[0]---[4294967295]
[EMAIL PROTECTED] tmp]$
/home/dinar/work/gcc-builds/gnu/gcc-i686-pc-linux-gnu/bin/gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../configure
--prefix=/home/dinar/work/gcc-builds/gnu/gcc-i686-pc-linux-gnu/
--enable-languages=c,c++
Thread model: posix
gcc version 4.1.0 20050429 (experimental)
--
Summary: wrong result of 'if' statement with comparing of
floating point with gcc.
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dtemirbulatov at ru dot mvista dot com
CC: dtemirbulatov at ru dot mvista dot com,gcc-bugs at gcc
dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21360
[Bug libstdc++/21334] Lack of Posix compliant thread safety in std::basic_string
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-03 15:06 --- (In reply to comment #24) This message, including any attachments may contain confidential and privileged material; it is intended only for the person to whom it is ... Can you stop attaching this message to the email messages since it is wrong and not really valid for any open mailing list? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21334
[Bug middle-end/21360] wrong result of 'if' statement with comparing of floating point with gcc.
-- What|Removed |Added Component|c |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21360
[Bug middle-end/21360] wrong result of 'if' statement with comparing of floating point with gcc.
--- Additional Comments From dtemirbulatov at ru dot mvista dot com 2005-05-03 15:09 --- Created an attachment (id=8806) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8806action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21360
[Bug c++/21361] New: sizeof() packed structs potential errors
The following code produces different output in gcc4.0.0 and MSVC++7 .NET.
Additionally, I've tried 3.4.3 20050227 (Red Hat 3.4.3-22.fc3) and gcc 3.3.4
20040817 (Red Hat Linux 3.3.4-2), who all produce the same output as gcc4.0.0.
I'm unsure who is right here (don't know the exact C++ standards). If gcc4 is
right and MSVC++ is wrong this bug is invalid.
CODE:
#include stdio.h
#define DEFSTR(name) \
typedef struct name { \
unsigned int var : 13; \
};
#pragma pack(push, 1)
DEFSTR(pack1_struct)
#pragma pack(pop)
#pragma pack(push, 2)
DEFSTR(pack2_struct)
#pragma pack(pop)
#pragma pack(push, 4)
DEFSTR(pack4_struct)
#pragma pack(pop)
#pragma pack(push, 8)
DEFSTR(pack8_struct)
#pragma pack(pop)
#pragma pack(push, 16)
DEFSTR(pack16_struct)
#pragma pack(pop)
DEFSTR(unpacked_struct)
int main( int argc, char** argv ) {
printf(sizeof(pack1_struct) = %u\n, sizeof(pack1_struct) );
printf(sizeof(pack2_struct) = %u\n, sizeof(pack2_struct) );
printf(sizeof(pack4_struct) = %u\n, sizeof(pack4_struct) );
printf(sizeof(pack8_struct) = %u\n, sizeof(pack8_struct) );
printf(sizeof(pack16_struct) = %u\n, sizeof(pack16_struct) );
printf(sizeof(unpacked_struct) = %u\n, sizeof(unpacked_struct) );
return 0;
}
PRODUCES ON GCC:
sizeof(pack1_struct) = 2
sizeof(pack2_struct) = 2
sizeof(pack4_struct) = 4
sizeof(pack8_struct) = 4
sizeof(pack16_struct) = 4
sizeof(unpacked_struct) = 4
PRODUCES ON MSVC++7:
sizeof(pack1_struct) = 4
sizeof(pack2_struct) = 4
sizeof(pack4_struct) = 4
sizeof(pack8_struct) = 4
sizeof(pack16_struct) = 4
sizeof(unpacked_struct) = 4
--
Summary: sizeof() packed structs potential errors
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: moudekotte at khaeon dot nl
CC: gcc-bugs at gcc dot gnu dot org
GCC host triplet: i686-redhat-linux
GCC target triplet: i386-redhat-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21361
[Bug middle-end/20606] ICE in make_edges, at cfgbuild.c:327 on x86_64 (with O2 - not with no optimizations)
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |aph at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20606
[Bug middle-end/21360] wrong result of 'if' statement with comparing of floating point with gcc.
--- Additional Comments From dtemirbulatov at ru dot mvista dot com 2005-05-03 15:11 --- Created an attachment (id=8807) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8807action=view) proposed patch -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21360
[Bug middle-end/21360] wrong result of 'if' statement with comparing of floating point with gcc.
-- What|Removed |Added Known to fail||3.4.0 4.0.0 4.1.0 Known to work||3.3.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21360
[Bug fortran/21359] gfortran internal error
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-03 15:17 --- Confirmed, reduced testcaseL program bug real :: t_intersect(2) t_intersect(minloc(t_intersect)) = 1.e10 end program Related to PR 21063. -- What|Removed |Added BugsThisDependsOn||21063 Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||ice-on-valid-code Last reconfirmed|-00-00 00:00:00 |2005-05-03 15:17:31 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21359
[Bug bootstrap/21288] bootstrap issues with profiledbootstrap
--- Additional Comments From bh at techhouse dot brown dot edu 2005-05-03 15:18 --- My (apparently broken) gmp is: rpm -qf /usr/lib/libgmp.so.3.3.2 gmp-4.1.2-2 Downloading a new GMP (4.1.4, which creates libgmp.so.3.3.3) appears to work. I wonder if it's easy to check for this situation? Anyway, thanks for the hint. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21288
[Bug middle-end/21360] [3.4/4.0/4.1 Regression] wrong result of 'if' statement with comparing of floating point with gcc.
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-03 15:21 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||wrong-code Last reconfirmed|-00-00 00:00:00 |2005-05-03 15:21:14 date|| Summary|wrong result of 'if'|[3.4/4.0/4.1 Regression] |statement with comparing of|wrong result of 'if' |floating point with gcc.|statement with comparing of ||floating point with gcc. Target Milestone|--- |3.4.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21360
[Bug bootstrap/21288] bootstrap issues with profiledbootstrap
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-03 15:21 --- Closing as works for me, a GMP bug. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21288
Re: [Bug other/21350] configure reports only a warning when bison is not installed
pinskia at gcc dot gnu dot org [EMAIL PROTECTED] writes: | Are you building from the source tarball or from CVS? | If from the source tarball, you don't need bison which is why it is just a warning. | Otherwise this is a bug in the release process if bison is now required (and a regression). | What is the current error you are getting building GCC? The problem as I was able to reproduce on Peter's machine yesterday is the following: gcc-core from release repository does not seem to contain w pregenerated c-parse.c. At build time, the build machiery attempts to generate it from c-parse.in and was looking for bison which Peter did not have. For some reasons the build did not stop for clear and unambiguous reason, (and even sooner aat configure time). If we now require bison for gcc-core, then we should check that at configure time and abort. -- Gaby
[Bug other/21350] configure reports only a warning when bison is not installed
--- Additional Comments From gdr at integrable-solutions dot net 2005-05-03 15:24 --- Subject: Re: configure reports only a warning when bison is not installed pinskia at gcc dot gnu dot org [EMAIL PROTECTED] writes: | Are you building from the source tarball or from CVS? | If from the source tarball, you don't need bison which is why it is just a warning. | Otherwise this is a bug in the release process if bison is now required (and a regression). | What is the current error you are getting building GCC? The problem as I was able to reproduce on Peter's machine yesterday is the following: gcc-core from release repository does not seem to contain w pregenerated c-parse.c. At build time, the build machiery attempts to generate it from c-parse.in and was looking for bison which Peter did not have. For some reasons the build did not stop for clear and unambiguous reason, (and even sooner aat configure time). If we now require bison for gcc-core, then we should check that at configure time and abort. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21350
[Bug java/21362] New: ICE in make_edges, at cfgbuild.c:327
Compiling the attached jarfile with optimisation fails with gcj (GCC) 4.0.0 20050423 (Red Hat 4.0.0-2). $ gcj -findirect-dispatch -shared bork.jar # works $ gcj -findirect-dispatch -shared -O bork.jar org/apache/catalina/session/FileStore.java: In class 'org.apache.catalina.session.FileStore': org/apache/catalina/session/FileStore.java: In method 'org.apache.catalina.session.FileStore.save(org.apache.catalina.Session)': org/apache/catalina/session/FileStore.java:0: internal compiler error: in make_edges, at cfgbuild.c:327 -- Summary: ICE in make_edges, at cfgbuild.c:327 Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: gbenson at redhat dot com CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu dot org GCC target triplet: i386-redhat-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21362
[Bug java/21362] ICE in make_edges, at cfgbuild.c:327
--- Additional Comments From gbenson at redhat dot com 2005-05-03 15:26 --- Created an attachment (id=8808) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8808action=view) Testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21362
[Bug other/21350] [4.0/4.1 Regression] build now requires bision
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-03 15:26 --- Ok, we don't require bison at least before, sounds like the release package is messed up. -- What|Removed |Added CC|gdr at cs dot tamu dot edu |gdr at gcc dot gnu dot org Status|WAITING |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-05-03 15:27:00 date|| Summary|configure reports only a|[4.0/4.1 Regression] build |warning when bison is not |now requires bision |installed | Target Milestone|--- |4.0.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21350
[Bug java/21362] ICE in make_edges, at cfgbuild.c:327
--- Additional Comments From gbenson at redhat dot com 2005-05-03 15:27 --- This is possibly the same as bug 20606. -- What|Removed |Added Keywords||ice-on-valid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21362
[Bug other/21350] [4.0/4.1 Regression] build now requires bision
--- Additional Comments From gdr at integrable-solutions dot net 2005-05-03 15:43 --- Subject: Re: [4.0/4.1 Regression] build now requires bision pinskia at gcc dot gnu dot org [EMAIL PROTECTED] writes: |What|Removed |Added | | CC|gdr at cs dot tamu dot edu |gdr at gcc dot gnu dot org Thanks! :-) -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21350
[Bug java/21362] ICE in make_edges, at cfgbuild.c:327
--- Additional Comments From gbenson at redhat dot com 2005-05-03 15:53 --- Created an attachment (id=8809) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8809action=view) Testcase source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21362
[Bug libstdc++/21334] Lack of Posix compliant thread safety in std::basic_string
--- Additional Comments From jkanze at cheuvreux dot com 2005-05-03 15:57 --- Subject: Re: Lack of Posix compliant thread safety in std::basic_string | This message, including any attachments may contain confidential and | privileged material; it is intended only for the person to whom it is | ... | Can you stop attaching this message to the email messages since | it is wrong and not really valid for any open mailing list? Regretfully no. For reasons beyond my fathoming, we have to use Lotus Notes on a Windows machine for all external email, and they've set up the Notes server to add this trailer (which as you correctly point out, doesn't make much sense in a lot of contexts.) It's particularly painful, because there is no development environment on the Windows machine, so I have to ftp any code samples to and from the Solaris boxes. Next time, I'll wait until I'm at home to report an error; my Linux box doesn't have any of these problems:-). (To be fair, Windows doesn't have to be this bad, either; I've worked in places where it was actually usable.) -- James Kanze This message, including any attachments may contain confidential and privileged material; it is intended only for the person to whom it is addressed. Its contents do not constitute a commitment by Credit Agricole Cheuvreux except where provided for in a written agreement. Credit Agricole Cheuvreux assumes no liability or responsibility for the consequences arising out of a delay and/or loss in transit of this message, or for corruption or other error(s) arising in its transmission and for any misuse or fraudulent use which may be made thereof. If you are not the intended recipient, please contact us and abstain from any disclosure, use or dissemination. To the extent that this message contains research information and/or recommendations, these are provided on the same basis as Credit Agricole Cheuvreux's published research and the recipient must have regard to all disclosures and disclaimers contained therein. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21334
[Bug tree-optimization/21356] [4.1 Regression] Dominance error after aggressive dead code elimination (cd_dce)
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-03 16:00 --- Confirmed, a regression from 4.0.0. -- What|Removed |Added Status|UNCONFIRMED |NEW Component|middle-end |tree-optimization Ever Confirmed||1 Keywords||ice-on-valid-code Last reconfirmed|-00-00 00:00:00 |2005-05-03 16:00:08 date|| Summary|Dominance error after |[4.1 Regression] Dominance |aggressive dead code|error after aggressive dead |elimination (cd_dce)|code elimination (cd_dce) Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21356
Re: [Bug libstdc++/21334] Lack of Posix compliant thread safety in std::basic_string
jkanze at cheuvreux dot com [EMAIL PROTECTED] writes: Regretfully no. For reasons beyond my fathoming, we have to use Lotus Notes on a Windows machine for all external email, and they've set up the Notes server to add this trailer (which as you correctly point out, doesn't make much sense in a lot of contexts.) It's particularly painful, because there is no development environment on the Windows machine, so I have to ftp any code samples to and from the Solaris boxes. Note that these disclaimers are expressly against gcc mailing list policy, as described here: http://gcc.gnu.org/lists.html With respect to filing a bug, you can make entries directly into the bug at http://gcc.gnu.org/bugzilla/ to avoid this problem. Otherwise please send e-mail from a different account, as you mention. Free web based e-mail accounts are readily available.
[Bug java/21362] ICE in make_edges, at cfgbuild.c:327
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |aph at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-05-03 16:08:56 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21362
[Bug middle-end/20606] ICE in make_edges, at cfgbuild.c:327 on x86_64 (with O2 - not with no optimizations)
--- Additional Comments From aph at gcc dot gnu dot org 2005-05-03 16:10 --- See also PR 21362 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20606
[Bug middle-end/20606] ICE in make_edges, at cfgbuild.c:327 on x86_64 (with O2 - not with no optimizations)
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-03 16:15 --- We no longer fail with this code on the mainline but most likely because actually thread the jump which I was taking in comment #5. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20606
[Bug target/19933] Problem with define of HUGE_VAL in math_c99.
--- Additional Comments From joseph at codesourcery dot com 2005-05-03 16:21 --- Subject: Re: Problem with define of HUGE_VAL in math_c99. On Tue, 3 May 2005, ebotcazou at gcc dot gnu dot org wrote: 1. Can we work around bug 20558 by using the sizeof trick for isinf? No, because all of __builtin_isinf, __builtin_isinff, __builtin_isinfl may fall back to library functions isinf, isinff, isinfl and Solaris libc/libm doesn't have those functions. 2. Can we use __builtin_finite for isfinite? No, because again all the __builtin_finite* functions may fall back to library functions and the only one of those Solaris has is plain finite. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19933
[Bug target/21351] internal compiler error with sse
-- What|Removed |Added GCC host triplet|gcc version 3.4.4 20050429 | |(prerelease) [FreeBSD] | GCC target triplet||i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21351
[Bug c++/21363] New: no compilation error for inheriting Base class with private constructor when the constructor for Derived Class is compiler generated
The following code generate a compilation error:
class Foo {
private:
Foo() { }
};
class Bar : public Foo
{
public:
Bar() {}
};
int main()
{
return 0;
}
however,commenting out Bar(){} (i.e. let the compiler generate one for me),do
not cause any compilation error.
the same case for virtual base constructor(in which I discover it when reading
C++ faq 23.9)
class FooBase
{
friend class Foo;
private:
FooBase();
};
class Foo : virtual private FooBase
{
public:
Foo() { }
};
class Bar : private virtual Foo
{
public:
Bar() {} //no error if comment it out
};
int main()
{
return 0;
}
test on gcc 3.3 and gcc 3.4 in debian:
g++-3.4 (GCC) 3.4.4 20050314 (prerelease) (Debian 3.4.3-12)
g++-3.3 (GCC) 3.3.5 (Debian 1:3.3.5-12)
--
Summary: no compilation error for inheriting Base class with
private constructor when the constructor for Derived
Class is compiler generated
Product: gcc
Version: 3.3.5
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hingwah at hingwah dot net
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21363
[Bug middle-end/21360] [3.4/4.0/4.1 Regression] wrong result of 'if' statement with comparing of floating point with gcc.
--- Additional Comments From jsm28 at gcc dot gnu dot org 2005-05-03 16:33 --- Conversion of out-of-range floating point values to integers yields undefined behavior in both C and C++. There is no need for it to be consistent between compile-time and runtime conversions. However, the ISO C decimal floating point proposals (DTR 24732 / WG14 N1107) make it well-defined for binary as well as decimal floating-point types. So we do want to support well-defined semantics (namely, those in that proposal) for both compile-time and runtime conversions, at least under a command-line option to enable them. I don't know whether dfp-branch has such support yet. Performance measurements would be needed to ascertain whether there is any benefit to having both versions or whether we might as well just always use the DTR 24732 semantics for these conversions (and document that we are doing so, and seek out and eliminate any optimizations in the compiler which depend on such conversions being undefined - a search for such optimizations being a necessary part of the decimal floating point work anyway if not already done). -- What|Removed |Added CC||bje at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21360
[Bug middle-end/20606] ICE in make_edges, at cfgbuild.c:327 on x86_64 (with O2 - not with no optimizations)
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-03 16:36 --- (In reply to comment #8) We no longer fail with this code on the mainline but most likely because actually thread the jump which I was taking in comment #5. Let me rewrite that. This now works on the mainline. This is most likely due to the jump threading changes in which we actually catch the threading on the tree level instead of waiting until the RTL level which causes the bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20606
[Bug target/21325] [4.0 Regression] libjava should be re-enabled for ppc-darwin
--- Additional Comments From andreast at gcc dot gnu dot org 2005-05-03
16:47 ---
Index: configure.in
===
RCS file: /cvs/gcc/gcc/configure.in,v
retrieving revision 1.341.2.2
diff -u -r1.341.2.2 configure.in
--- configure.in21 Apr 2005 02:45:11 - 1.341.2.2
+++ configure.in3 May 2005 16:45:18 -
@@ -364,7 +364,7 @@
noconfigdirs=$noconfigdirs target-newlib target-libgloss ${libgcj}
;;
powerpc-*-darwin*)
-noconfigdirs=$noconfigdirs bfd binutils ld gas opcodes gdb gprof
${libgcj}
+noconfigdirs=$noconfigdirs bfd binutils ld gas opcodes gdb gprof
;;
*-*-darwin*)
noconfigdirs=$noconfigdirs bfd binutils ld gas opcodes gdb gprof
Tested on powerpc-apple-darwin7.9.0 with awt enabled. Built ok.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21325
[Bug target/16888] [3.3/3.4 Regression] ICE: in print_reg, at config/i386/i386.c:7254
-- What|Removed |Added AssignedTo|aoliva at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW Summary|[3.3/3.4/4.0/4.1 Regression]|[3.3/3.4 Regression] ICE: |ICE: in print_reg, at |in print_reg, at |config/i386/i386.c:7254 |config/i386/i386.c:7254 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16888
[Bug target/16888] [3.3/3.4 Regression] ICE: in print_reg, at config/i386/i386.c:7254
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-03 17:00 --- Subject: Bug 16888 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-05-03 17:00:26 Modified files: gcc: ChangeLog gcc/config/i386: i386.h gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.target/i386: asm-1.c Log message: gcc/ChangeLog: PR target/16888 * config/i386/i386.h (CONDITIONAL_REGISTER_USAGE): Clear reg names for unavailable registers. gcc/testsuite/ChangeLog: PR target/16888 * gcc.target/i386/asm-1.c: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=2.7592.2.213r2=2.7592.2.214 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/i386/i386.h.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.421.6.2r2=1.421.6.3 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.5084.2.154r2=1.5084.2.155 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.target/i386/asm-1.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=NONEr2=1.1.2.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16888
[Bug target/16888] [3.3/3.4 Regression] ICE: in print_reg, at config/i386/i386.c:7254
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-03 17:01 --- Subject: Bug 16888 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-05-03 17:01:01 Modified files: gcc: ChangeLog gcc/config/i386: i386.h gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.target/i386: asm-1.c Log message: gcc/ChangeLog: PR target/16888 * config/i386/i386.h (CONDITIONAL_REGISTER_USAGE): Clear reg names for unavailable registers. gcc/testsuite/ChangeLog: PR target/16888 * gcc.target/i386/asm-1.c: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.8579r2=2.8580 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/i386/i386.h.diff?cvsroot=gccr1=1.432r2=1.433 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.5435r2=1.5436 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.target/i386/asm-1.c.diff?cvsroot=gccr1=1.1r2=1.2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16888
[Bug c++/21363] no compilation error for inheriting Base class with private constructor when the constructor for Derived Class is compiler generated
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-03 17:06 --- I think this is how C++ works. Or this because of the lazy createness of constructors. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21363
[Bug translation/21364] New: [translation] %J in translation instead of %H causes ICE in de.po
[de.po] #: tree-ssa.c:1379 msgid %H%qD is used uninitialized in this function msgstr %J%qD wird in dieser Funktion uninitialisiert verwendet The %J causes gcc to segfault. Changing it to %H fixes everything, obviously. Besides, the `q' modifier in %qD doesn't seem to be honoured in the translated string (same for % and % which are only interpreted in the original english string). I fixed up tons of lines some days ago myself, I found a bunch of entries where the fuzzy selector picked a wrong translation and I've probably overlooked some. If someone is interested...? I don't know to do exactly (so please don't shoot me), it seems someone has written some sort of script to check that the dynamic parameters are the same in both message strings. -- Summary: [translation] %J in translation instead of %H causes ICE in de.po Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: translation AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: christophe at saout dot de CC: gcc-bugs at gcc dot gnu dot org GCC host triplet: *-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21364
[Bug libgcj/21285] gij fails to handle NullPointerException exception
--- Additional Comments From tromey at gcc dot gnu dot org 2005-05-03 18:23 --- Could you run gij under gdb and attach a stack trace to this PR? That might help. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21285
[Bug translation/21364] [translation] %J in translation instead of %H causes ICE in de.po
--- Additional Comments From jsm28 at gcc dot gnu dot org 2005-05-03 18:24 --- The specific translation issue you mention will need to be dealt with by the translators. I don't know why you say %q isn't honoured, the translation includes translations for the opening and closing quotes and they seem to be used, but you didn't give either a testcase or your locale settings. All patches to translations must be sent to the translators. I will ask [EMAIL PROTECTED] to add a Bugzilla account so bugs such as this can be assigned to them. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-05-03 18:24:29 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21364
[Bug libfortran/20930] [4.0/4.1 Regression] gfortran.dg/backspace.f execution test
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-03 18:24 --- (In reply to comment #7) John, does this work now? Ping, -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20930
[Bug libgcj/21326] seg fault in _Jv_Linker
--- Additional Comments From tromey at gcc dot gnu dot org 2005-05-03 18:29 --- I didn't download the source to try this out. But based on the stack trace, I think the problem is probably that a class compiled with the C++ ABI is referring to an org.xml class. This doesn't work, as these classes are compiled with the BC ABI (i.e., -findirect-dispatch). This is unfortunate, but necessary to support java.endorsed.dirs. The restriction that a C++ ABI class can't directly refer to a BC ABI class is unlikely to be lifted. The fix is to compile your program with -findirect-dispatch. (But note that at the moment this only works when compiling from .class) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21326
[Bug bootstrap/21365] New: libiberty/regex.c:49:25: error: sys/types.h: No such file or directory
This is BASH 2.05b - DISPLAY on Tue May 3 11:29:07 PST 2005 bash-2.05b$ cd f:/temp/obj1/ bash-2.05b$ ls Makefile config.cache config.status* gcc/ libcpp/ multilib.out sh3-elf/ build-i686-pc-cygwin/ config.logfixincludes/intl/ libiberty/ serdep.tmp bash-2.05b$ make all make[1]: Entering directory `/cygdrive/f/temp/obj1/libiberty' make[2]: Entering directory `/cygdrive/f/temp/obj1/libiberty/testsuite' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/cygdrive/f/temp/obj1/libiberty/testsuite' make[1]: Leaving directory `/cygdrive/f/temp/obj1/libiberty' make[1]: Entering directory `/cygdrive/f/temp/obj1/fixincludes' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/cygdrive/f/temp/obj1/fixincludes' make[1]: Entering directory `/cygdrive/f/temp/obj1/intl' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/cygdrive/f/temp/obj1/intl' make[1]: Entering directory `/cygdrive/f/temp/obj1/build-i686-pc- cygwin/libiberty' make[2]: Entering directory `/cygdrive/f/temp/obj1/build-i686-pc- cygwin/libiberty/testsuite' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/cygdrive/f/temp/obj1/build-i686-pc- cygwin/libiberty/testsuite' make[1]: Leaving directory `/cygdrive/f/temp/obj1/build-i686-pc- cygwin/libiberty' make[1]: Entering directory `/cygdrive/f/temp/obj1/build-i686-pc- cygwin/fixincludes' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/cygdrive/f/temp/obj1/build-i686-pc- cygwin/fixincludes' make[1]: Entering directory `/cygdrive/f/temp/obj1/libcpp' test -f config.h || (rm -f stamp-h1 make stamp-h1) make[1]: Leaving directory `/cygdrive/f/temp/obj1/libcpp' make[1]: Entering directory `/cygdrive/f/temp/obj1/gcc' if [ -f fixhdr.ready ] ; then \ true; \ else \ echo timestamp fixhdr.ready; \ fi make \ CFLAGS=-g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing- prototypes -fno-common \ CONFIG_H=config.h auto-host.h .././../gcc-4.1- 20050424/gcc/../include/ansidecl.h .././../gcc-4.1-20050424/gcc/config /i386/xm-cygwin.h \ MAKEOVERRIDES= \ -f libgcc.mk all make[2]: Entering directory `/cygdrive/f/temp/obj1/gcc' make GCC_FOR_TARGET=/cygdrive/f/temp/obj1/./gcc/xgcc - B/cygdrive/f/temp/obj1/./gcc/ -B/superH/sh3-elf/bin/ -B/superH/sh 3-elf/lib/ -isystem /superH/sh3-elf/include -isystem /superH/sh3-elf/sys- include \ AR_FOR_TARGET=sh3-elf-ar \ AR_CREATE_FOR_TARGET=sh3-elf-ar rc \ AR_EXTRACT_FOR_TARGET=sh3-elf-ar x \ AR_FLAGS_FOR_TARGET= \ CC=gcc CFLAGS=-g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes - Wmissing-prototypes -fno-common \ BUILD_PREFIX= \ BUILD_PREFIX_1=loser- \ LANGUAGES= \ LIBGCC2_CFLAGS=-O2 -DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings - Wstrict-prototypes -Wmissing-prototypes -Wol d-style-definition -isystem ./include -g -DIN_LIBGCC2 - D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc \ MULTILIB_CFLAGS= T= crt1.o crti.o crtn.o crtbegin.o crtend.o crtbeginS.o crtendS.o make[3]: Entering directory `/cygdrive/f/temp/obj1/gcc' make[3]: `crti.o' is up to date. make[3]: `crtn.o' is up to date. make[3]: `crtend.o' is up to date. make[3]: `crtbeginS.o' is up to date. make[3]: `crtendS.o' is up to date. make[3]: Leaving directory `/cygdrive/f/temp/obj1/gcc' make[2]: Leaving directory `/cygdrive/f/temp/obj1/gcc' echo timestamp stmp-multilib make[1]: Leaving directory `/cygdrive/f/temp/obj1/gcc' Checking multilib configuration... multilib.out is unchanged make[1]: Entering directory `/cygdrive/f/temp/obj1/sh3-elf/libiberty' if [ x != x ]; then \ /cygdrive/f/temp/obj1/./gcc/xgcc -B/cygdrive/f/temp/obj1/./gcc/ -B/superH/sh3- elf/bin/ -B/superH/sh3-elf/lib/ -isystem /superH/sh3-elf/include -isystem /superH/sh3-elf/sys-include -c - DHAVE_CONFIG_H -O2 -g -O2 -I. -I../.././../gcc-4.1-20 050424/libiberty/../include -W -Wall -pedantic -Wwrite-strings -Wstrict- prototypes ../.././../gcc-4.1-20050424/libiber ty/regex.c -o pic/regex.o; \ else true; fi /cygdrive/f/temp/obj1/./gcc/xgcc -B/cygdrive/f/temp/obj1/./gcc/ -B/superH/sh3- elf/bin/ -B/superH/sh3-elf/lib/ -isystem / superH/sh3-elf/include -isystem /superH/sh3-elf/sys-include -c -DHAVE_CONFIG_H - O2 -g -O2 -I. -I../.././../gcc-4.1-2005 0424/libiberty/../include -W -Wall -pedantic -Wwrite-strings -Wstrict- prototypes ../.././../gcc-4.1-20050424/libiberty/ regex.c -o regex.o ../.././../gcc-4.1-20050424/libiberty/regex.c:49:25: error: sys/types.h: No such file or directory ../.././../gcc-4.1-20050424/libiberty/regex.c:128: warning: function declaration isn't a prototype ../.././../gcc-4.1-20050424/libiberty/regex.c:128: warning: conflicting types for built-in function 'malloc' ../.././../gcc-4.1-20050424/libiberty/regex.c:129: warning: function declaration isn't a prototype ../.././../gcc-4.1-20050424/libiberty/regex.c:156:25: error: strings.h: No such file or directory In file included from ../.././../gcc-4.1- 20050424/libiberty/../include/xregex.h:26,
[Bug driver/21366] New: The -bundle linking option does not get processed right on darwin
When compiling a module with -bundle the -bundle does not get passed right. It results in an unknown option undle. -- Summary: The -bundle linking option does not get processed right on darwin Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: driver AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: andreast at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: powerpc-apple-darwin* GCC host triplet: powerpc-apple-darwin* GCC target triplet: powerpc-apple-darwin* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21366
