Re: how to convince someone about migrating from gcc-2.95 to gcc-3.x
On Apr 1, 2007, at 10:42 PM, Joe Buck wrote: On Sun, Apr 01, 2007 at 02:20:10PM +0200, Marcin Dalecki wrote: Wiadomość napisana w dniu 2007-04-01, o godz13:58, przez Paul Brook: If you're already switching compilers, moving to an already obsolete release (3.3) seems a strange choice. At this point I'd recommend skipping 3.x altogether and going straight to gcc4.1/4.2. Many of the improvements in c++ code generation were as a result of tree-ssa, you only get with 4.x. I wouldn't recommend it. One has to adapt gradually to the patience required to use the later compiler editions. No, one does not have to adapt gradually. It is no harder to switch from 2.95 to 4.1.2 than it is to switch from 2.95 to 3.3. Either way, you'll have to get out a C++ book, learn C++, and recode your code in actual C++. There will be some cases where going to 3.3 will require fewer changes, but the majority of the work is going to have to be done anyway. I believe the point being made was about compile times, not conformance. -Chris
RE: Information regarding -fPIC support for Interix gcc
Hi Murali/Everybody 1: I am keen on understanding how does the offset of L32 from _GLOBAL_OFFSET_TABLE_ generated ? I mean if assembly is Movl [EMAIL PROTECTED](%ebx,%eax),%eax then how does is gets converted to mov 0xbd14(%eax,%ebx,1),%eax. I guessed that L32 is at start of .rodata section which is the only section of its type. So in my opinion it should have been Address of .got section - address of .rodata section. But I am not getting the generated offset seen in objdump as the same as I calculate from the above method on a FreeBSD box. Can anyone help here ? On interix, the offset is being calculated as .got - .rodata only, so is there anything wrong in this? I am assuming that this is the only thing that could be going wrong. 2: Murali, Interix generated pecoff binaries have _GLOBAL_OFFSET_TABLE_ defined. We also have .got section/.plt section etc which are present in a pic compiled code, hence your patch may fix the problem in an alternate way but may not be the correct fix for Interix. Yes , you are right that the generated assembly is for a switch case and is actually a jump table. 3: Also, after further investigation, I found that Interix compiled shared libraries with fPIC flag only cause a crash when there is a jump table being created for a switch case. I compiled the same shared library which was crashing with ---fPIC and -fno-jump-table on 4.3 and it worked great. So are there any jump table experts out there who could help me investigate what is going wrong in there? I have attached objdump -D output and gcc -S output for the shared library(repro code which is basically a small dummy library). --Ass contains objdump -D output --lib1.s contains gcc -S output Look at the jump table generated for switch case inside func1_1? This causes the crash because the control jumps to invalid location thru jmp*%eax. Thanks Mayank -Original Message- From: Murali Vemulapati [mailto:[EMAIL PROTECTED] Sent: Saturday, March 31, 2007 9:57 PM To: Mayank Kumar Cc: gcc@gcc.gnu.org Subject: Re: Information regarding -fPIC support for Interix gcc On 3/31/07, Mayank Kumar [EMAIL PROTECTED] wrote: Further to this email, I did some more investigation, here is some more detailed information about what I am doing:- 1: Compiled a shared library(tcl8.4.14) using -fPIC on gcc4.3.0 for interix(was able to compile gcc 4.3.0 for interix) 2: The assembly generated for a particular region of code which causes a jmp to an invalid location, obtained using gcc -S -fPIC is as follows:- movl-20(%ebp), %eax sall$2, %eax movl[EMAIL PROTECTED](%ebx,%eax), %eax addl%ebx, %eax jmp *%eax .section.rdata,r .balign 4 L32: .long [EMAIL PROTECTED] 3:the assembly generated while executing the binary linked with the shared library 0x100889dc Tcl_ConvertCountedElement+246: mov0xffec(%ebp),%eax 0x100889df Tcl_ConvertCountedElement+249: shl$0x2,%eax 0x100889e2 Tcl_ConvertCountedElement+252: mov 0xbd14(%eax,%ebx,1),%eax 0x100889e9 Tcl_ConvertCountedElement+259: add%ebx,%eax 0x100889eb Tcl_ConvertCountedElement+261: jmp*%eax 4:Similar code compiled and run on a FreeBsd box using gcc shared library and fPIC produces the following assembly:- 0x2810a1a8 Tcl_ConvertCountedElement+244: mov0xffec(%ebp),%eax 0x2810a1ab Tcl_ConvertCountedElement+247: shl$0x2,%eax 0x2810a1ae Tcl_ConvertCountedElement+250: mov 0x4f14(%eax,%ebx,1),%eax 0x2810a1b5 Tcl_ConvertCountedElement+257: add%ebx,%eax 0x2810a1b7 Tcl_ConvertCountedElement+259: jmp*%eax 5:So corresponding to ---movl[EMAIL PROTECTED](%ebx,%eax), %eax, The assembly generated on interix is --- mov0xbd14(%eax,%ebx,1),%eax Whereas on bsd box, it is --- mov0x4f14(%eax,%ebx,1),%eax Here the offset bd14 in case of interix is wrong which is causing the jmp *eax to jump to a different function. Now my questions are:- 1: What does [EMAIL PROTECTED] mean ? Is it at offset L32 in GOTOFF table ? It means the offset of L32 from the symbol GLOBAL_OFFSET_TABLE. It looks like this refers to a switch table. It is indexing into a jump table and jmping to that label. 2: Shld the value of [EMAIL PROTECTED] remain same for all machines for which the same library/binary is compiled? 3: Does the above mean that the GLOBAL_OFFSET_TABLE is not being populated correctly ? If that is so, why would this be interix specific? The Global Offset Table (GOT) is generated by the linker. But this is specific to Elf binaries. The PECOFF ABI does not define a GOT. Nor does it support the relocation types R_386_GOTOFF and R_386_GOT32. 4: I can see these offset's with objdump -D also, so I concluded that this could not be a linker or loader issue but a compiler issue only. Which part of gcc code should I refer for
Re: how to convince someone about migrating from gcc-2.95 to gcc-3.x
hi if not for the real compiler as such, what advantages would i get on using newer glibc, libstdc++ ?? would these features be tied to some kernel version linux-2.4 vs 2.6 ( something like thread support). thanks ganesh - Original Message From: Chris Lattner [EMAIL PROTECTED] To: Joe Buck [EMAIL PROTECTED] Cc: Marcin Dalecki [EMAIL PROTECTED]; Paul Brook [EMAIL PROTECTED]; gcc@gcc.gnu.org; Dave Korn [EMAIL PROTECTED]; ganesh subramonian [EMAIL PROTECTED] Sent: Monday, April 2, 2007 11:32:43 AM Subject: Re: how to convince someone about migrating from gcc-2.95 to gcc-3.x On Apr 1, 2007, at 10:42 PM, Joe Buck wrote: On Sun, Apr 01, 2007 at 02:20:10PM +0200, Marcin Dalecki wrote: Wiadomość napisana w dniu 2007-04-01, o godz13:58, przez Paul Brook: If you're already switching compilers, moving to an already obsolete release (3.3) seems a strange choice. At this point I'd recommend skipping 3.x altogether and going straight to gcc4.1/4.2. Many of the improvements in c++ code generation were as a result of tree-ssa, you only get with 4.x. I wouldn't recommend it. One has to adapt gradually to the patience required to use the later compiler editions. No, one does not have to adapt gradually. It is no harder to switch from 2.95 to 4.1.2 than it is to switch from 2.95 to 3.3. Either way, you'll have to get out a C++ book, learn C++, and recode your code in actual C++. There will be some cases where going to 3.3 will require fewer changes, but the majority of the work is going to have to be done anyway. I believe the point being made was about compile times, not conformance. -Chris No need to miss a message. Get email on-the-go with Yahoo! Mail for Mobile. Get started. http://mobile.yahoo.com/mail
Re: Extension for a throw-like C++ qualifier
I have for a while been working on a tool that performs static analysis
of exception propagation through C/C++ code. It is very close to
complete (I estimate the first release within the month).
Implementing static analysis of C++ exception propagation in g++ alone
is not really possible well at least not really feasible. The tool i
have been developing uses g++/gcc to obtain information about the code
so i can construct a complete pessimistic callgraph along with info
about exception usage, but it does not do it at compile time, rather it
has to perform the analysis at the equivalent to the linking stage to
get ALL the necessary information to construct this callgraph accurately.
The problem is for things like function pointers/virtual functions,
until you know exactly what code goes into a particular application you
can not be sure exactly what to expand the calls to. I.e. you will only
get a subset of possible calls from a single translation unit. To get
the full set of possible calls you need to look at ALL code that goes
into a particular application. (This becomes a nightmare to manage with
especially plugins and the like)
If ALL C++ code implemented a thing like in Java (Which i think is what
you are describing) where you can be guaranteed that a function only
throws certain exceptions and the compiler mandates this, then you can
achieve the same sort of results in a single translation unit, however
getting every project that uses C++ to adopt such techniques is just not
going to happen and without having all projects adopt this the usage
will become very difficult. I.e. you will either have to wrap the
function calls inside of try/catch blocks to meet the strict requirements.
Using something like that could be a nightmare... There would be catch
blocks all over the place that are used to filter out possible
exceptions from other peoples code that you just don't know if they are
going to occur. And what do you do if an exception does occur that you
were not expecting?
I think the idea is a great one. It works very well in Java. I still
dont understand why the C++ standard adopted the current throws()
mechanism (Who thought that terminating a program based on that
particular exceptoin condition that the compiler cant check for you was
a good idea? Hmm. I dont know a anyone who make use of the throws()
clauses very often unless they usually do throws() and do a catch all
and are not necessarily sure what exactly to do with what they caught
anyway) I think the whole mechanism comes from the history of the
language and so it has a semi-useful technique unlike Java where the
throws() clause works well.
I have written this application so that i can use the standard C++
mechanisms for indicating the exceptions that can occur, then i can run
my code through this tool and it will notify me of places where an
exception may occur that is contrary to what i have specified. This
means i can use the standard mechanisms and get the equivalent of a
compile error from my application when my assumptions are incorrect.
It basically assures me that I wont have my program terminate because of
this problem.
Anyhow, I could talk for a while about this... But if you are interested
more in this application then there is a partially complete website:
http://edoc.sourceforge.net/
As i said it is not yet complete but it is getting close. I will be
updating the website and the documentation again once i have completed
modifying the code. The only way to download the code at the moment is
from CVS and i would not recommend that just now. So it might be best to
wait and give it a try. You can read the rough manual for now to get
an idea of what EDoc++ can and cant do and how to use it.
I will hopefully be posting to this list later a shameless plug for this
application when it is all ready (I was going to ask the maintainer
first). I am interested in feedback on how it can be improved, but this
thread came up and i just could not pass the opportunity...
Brendon.
Sergio Giro wrote:
Maybe that the option you suggest
This is best
done with something like -fstatic-exception-specifications or maybe -
Wexception-specifications -Werror.
is ideal, but it seems to me not practical at all. Every stuff using
the throw qualifier as specified in the standards will not work. If an
inline method in a standard header is
theInlineMethod (void) throw () { throw theException(); };
this will not even compile...
Of course, using an extension as the one I propose, some of the
standard methods must be wrapped if you want to use the new qualifier
in order to track the possible exceptions that the methods may arise,
but I think it is quite more practical to wrap such methods than to
modify the headers...
In addition, the semantic meaning is not the same: a
throw (a,b,c) qualifier indicates that you are able only to catch the
exceptions a, b and c, and that every other exception will be seen as
std::unexpected.
Re: how to convince someone about migrating from gcc-2.95 to gcc-3.x
if not for the real compiler as such, what advantages would i get on using newer glibc, libstdc++ ?? would these features be tied to some kernel version linux-2.4 vs 2.6 ( something like thread support). Let's step back a bit. If you look at this page: http://gcc.gnu.org/releases.html The age differences and new features between releases become clear with some digging. From this, one sees the inception dates for various gcc releases: 2.95.x == July 31, 1999 3.4.x == April 18, 2004 4.1.x == February 28, 2006 If you clink on the version name link (say GCC 4.1.0), you'll go to an informative page (http://gcc.gnu.org/gcc-4.1/) that gives details on the release series. Clicking on the link that says changes will give you details about what changed in the GCC 4.1.0 release from the last release. Hopefully that makes answering this kind of question easier for you. For your specific questions: 1) between gcc-2.95.x and gcc-3.2.x, libstdc++ has been completely replaced. This new library is called libtdc++-v3 and implements the ISO standard. Noticeable differences between 2.95 are templatized iostreams, wide-character support, localization, namespace support, etc etc. Later versions include a Safe STL component in the libstdc++ debug mode, abstractions for threads, implementations for TR1, a performant std::string class in ext/__versa_string, various optimizing replacements for std:: allocators, etc. etc. 2) between gcc-2.95.x and gcc-3.2.x, gcc-3.2.x to gcc-3.3.x, and gcc-3.3.x to gcc-3.4.x, the C++ ABI implemented by the g++ compiler changed. This has been changed to implement and industry-standard C++ ABI. This is advantageous to you because with this ABI, g++ and other compilers can now inter-operate (assuming you are using compatible libstdc++ versions.) Ie, you can use both g++ and non-GNU compilers to compile your application, or parts of your application. 3) between gcc-3.3.x and gcc-3.4.x, the C++ parser in g++ has been completely replaced. This results in clearer error messages, and faster, more correct parsing. 4) between gcc-3.4.x and gcc-4.0.x, the underlying optimizers for GCC have been replaced, moving to an SSA form. As you can see, there has been considerable change in compilers and libraries in the almost 8 years since you changed tools. I'd suggest you start moving to a new toolset, if only on an experimental or provisional basis. Furthermore, I'd recommend a strategy of trying to update your toolset every two years or so, in order to spread out the work required to stay current with compilation technology. There will no doubt continue to be major advances in the C++ toolset with the upcoming C++0x ISO standard. And there will no doubt also be advances in language support (Open MP is added in gcc-4.2.x), and optimizer efficiency. best, benjamin
Re: Gcc and gfortran installation on MacBook Pro
Hi again, Here is the err_make file. Thanks, Aurélien 2007/3/30, François-Xavier Coudert [EMAIL PROTECTED]: out_make is the output of the make. In fact it is the output of the make launch a second time. (To big otherwise.) Yes, but it's missing the standard error file. Please use: make out_make 2 err_make or something similar. FX err_make Description: Binary data
Re: Gcc and gfortran installation on MacBook Pro
Hi, I have no idea of what is a gcc-4.2 snapshot ? Could you explain a bit. Thanks, Aurélien 2007/3/30, Mike Stump [EMAIL PROTECTED]: On Mar 30, 2007, at 7:45 AM, Aurélien Benoit-Lévy wrote: Do you have any idea of what went wrong and any idea of what should I do ? Hum, I'd be tempted to say, try a gcc-4.2 snapshot. If it doesn't work, we'll fix it for you. :-)
Re: How can I get VRP information for an RTX?
Andrew Pinski writes: On 4/1/07, David Daney [EMAIL PROTECTED] wrote: The issue is that for some things (the java front-end) we need the trapping behavior. I just want to optimize it if the divisor is known to be non-zero. VRP knows, but by the time we generate the code it seems that we have forgotten. The java front-end as far as I know emits a functon call always for targets that don't trap on divide by zero. I's sure David knows that. And as far as I know that is the x86 back-end which is the only target which traps really on divide by zero. We have handlers for GNU/Linux on PPC, x86, MIPS, S/390, and x86-64. For a while we didn't have a divide overflow handler on x86-64 because I didn't think it was worthwhile, but to my amazement the divide subroutine was taking up severeal percent of CPU time in real-world code. I think this is because divisions are used a lot to generate hash indexes. It seems wrong that the java front-end thinks we don't have to use the divide subroutine for MIPS. Really I think it is wrong that the mips back-end thinks it should enable by default trap on divide by zero. I'm not sure about that: the MIPS conditional trap instruction is quite efficient. Before making any change we should do some benchmarking. Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903
Re: Gcc and gfortran installation on MacBook Pro
Aurélien Benoit-Lévy writes: I have no idea of what is a gcc-4.2 snapshot ? Could you explain a bit. Why, instead, do you not simply go to http://gcc.gnu.org/ and follow thw link marked snapshots? Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903
Re: error: no newline at end of file
On 01/04/07, Martin Michlmayr [EMAIL PROTECTED] wrote: We have some real numbers about these new errors now. I've compiled the whole Debian archive in the last week for Gelato to test GCC 4.3 on IA64. Out of just slightly under 7000 packages in Debian, we have the following new failures: missing newline: 42 error: xxx redefined: 33 Martin, are those programs compiled with -pedantic or -pedantic-errors enabled? Cheers, Manuel.
Re: error: no newline at end of file
* Manuel López-Ibáñez [EMAIL PROTECTED] [2007-04-02 12:58]: missing newline: 42 error: xxx redefined: 33 Martin, are those programs compiled with -pedantic or -pedantic-errors enabled? Nope. -- Martin Michlmayr http://www.cyrius.com/
Re: wide chars with 16 BITS_PER_UNIT
On Fri, Mar 30, 2007 at 09:52:22AM -0700, Richard Henderson wrote: I think the problem is that we've not told libcpp what the correct narrow character set is. I suggest adding something like if (BITS_PER_UNIT = 32) cpp_opts-narrow_charset = BYTES_BIG_ENDIAN ? UTF-32BE : UTF-32LE; else if (BITS_PER_UNIT = 16) cpp_opts-narrow_charset = BYTES_BIG_ENDIAN ? UTF-16BE : UTF-16LE; Ah! That seems to do the trick. I'm still getting problems with numeric escapes, but I notice this comment in emit_numeric_escape: /* Note: this code does not handle the case where the target and host have a different number of bits in a byte. */ So my guess is that needs a fix too. I'm also seeing warnings from character literals like: warning: character constant too long for its type I should be able to chase this down too, though. Thanks for the help, Ned.
Re: error: no newline at end of file
On 02/04/07, Martin Michlmayr [EMAIL PROTECTED] wrote: * Manuel López-Ibáñez [EMAIL PROTECTED] [2007-04-02 12:58]: missing newline: 42 error: xxx redefined: 33 Martin, are those programs compiled with -pedantic or -pedantic-errors enabled? Nope. Then, if the warnings are not very useful but are mandated by the standard, I think that the sensible thing is to make them conditional on -pedantic. This way, people wanting strict diagnostics for nonconformant code can get them, while people that don't care about it don't need to suffer even a warning. Just out of curiosity, does any of those programs use -Werror? Thanks again, Manuel.
Re: error: no newline at end of file
* Manuel López-Ibáñez [EMAIL PROTECTED] [2007-04-02 13:57]: Just out of curiosity, does any of those programs use -Werror? No, otherwise the problems would have been found and fixed before. Remember, there has always been a warning about this, but now it's an error. -- Martin Michlmayr http://www.cyrius.com/
x86-64 -mcx16, picky __sync_val_compare_and_swap?
While doing (or trying to) some cleanup thanks to -mcx16, i've been a
bit surprised that
-- cut --
typedef int TItype __attribute__ ((mode (TI)));
TItype m_128;
void test(TItype x_128)
{
m_128 = __sync_val_compare_and_swap (m_128, x_128, m_128);
}
#include xmmintrin.h
typedef __m128i foo_t;
//typedef TItype foo_t;
foo_t foo;
void test2(foo_t x_128)
{
foo = __sync_val_compare_and_swap (foo, x_128, foo);
}
int main() { return 0; }
-- cut --
# /usr/local/gcc-4.3-20070323/bin/gcc -O2 -mcx16 xchg16.c -o xchg16
xchg16.c: In function 'test2':
xchg16.c:16: error: incompatible type for argument 1 of
'__sync_val_compare_and_swap'
# /usr/local/gcc-4.3-20070323/bin/gcc -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --prefix=/usr/local/gcc-4.3-20070323
--enable-languages=c++ --enable-threads=posix --with-system-zlib
--enable-__cxa_atexit --disable-checking --disable-nls
--disable-multilib --enable-bootstrap --with-gcc --with-gnu-as
--with-gnu-ld
Thread model: posix
gcc version 4.3.0 20070323 (experimental)
Am i just wrong believing that ought to work?
Re: error: no newline at end of file
On 02/04/07, Martin Michlmayr [EMAIL PROTECTED] wrote: * Manuel López-Ibáñez [EMAIL PROTECTED] [2007-04-02 13:57]: Just out of curiosity, does any of those programs use -Werror? No, otherwise the problems would have been found and fixed before. Remember, there has always been a warning about this, but now it's an error. Yes, you are right. Sorry, I forgot that Werror also affects pedwarns. Cheers, Manuel.
Re: How can I get VRP information for an RTX?
Andrew Haley wrote: Andrew Pinski writes: It seems wrong that the java front-end thinks we don't have to use the divide subroutine for MIPS. Really I think it is wrong that the mips back-end thinks it should enable by default trap on divide by zero. I'm not sure about that: the MIPS conditional trap instruction is quite efficient. Before making any change we should do some benchmarking. There are two issues: 1) Should the compiler generate a trap on division by zero? As far as I can tell, most mips compilers can be configured to generate a trap on division by zero. We should not remove this capability, just make it as efficient as possible. 2) Should the mips[el]-linux port of libgcj use trapping division? The JLS requires that an exception be thrown on division by zero. For the mips a division + conditional trap = 2 instructions and no branching. Calling the special libgcj divide function executes at least 4 times as many instructions and involves at least two jumps (call and return). I am not going to benchmark it. If you think there is a better way, you can benchmark it and report your findings. David Daney
Re: Extension for a throw-like C++ qualifier
On Apr 2, 2007, at 2:32 AM, Brendon Costa wrote: I have for a while been working on a tool that performs static analysis Ah, yeah, that I suspect would be a even better way to do this... Itt would be nice if gcc/g++ had more support for static analysis tools... Maybe with LTO.
Re: x86-64 -mcx16, picky __sync_val_compare_and_swap?
On Mon, Apr 02, 2007 at 04:23:21PM +0200, tbp wrote: Am i just wrong believing that ought to work? Yes. r~
Re: how to convince someone about migrating from gcc-2.95 to gcc-3.x
Joe Buck wrote: No, one does not have to adapt gradually. It is no harder to switch from 2.95 to 4.1.2 than it is to switch from 2.95 to 3.3. Either way, you'll have to get out a C++ book, learn C++, and recode your code in actual C++. There will be some cases where going to 3.3 will require fewer changes, but the majority of the work is going to have to be done anyway. And 4.1.x is much closer to what the textbooks say C++ is than 3.3 is. Why add to your pain? Furthermore, if you find that your progress is hampered by a bug in 3.3.x, no one is going to be interested in fixing it. I agree with Joe here, migrating to 3.3.x is the worst of both worlds, all the pain, and not all the gain!
Re: How can I get VRP information for an RTX?
Andrew Pinski [EMAIL PROTECTED] writes: Maybe one of the MIPS maintainers can explain why this option exists in the first place. As far as I can tell this has option has existed before the egcs/gcc split. I still say the back-end should not worry about this and divide by zero should always be declared as undefined. The GNU compiler acts as it does because that is how the old MIPS and SGI compilers acted. Ian
RE: -Wswitch-enum and -Wswitch-default
Therefore, only -Wswitch is enabled by -Wall but neither of Wswitch-default or Wswitch-enum are. The statement for -Wall says: -Wall All of the above `-W' options combined. This enables all the warnings about constructions that some users consider questionable, and that are easy to avoid (or modify to prevent the warning), even in conjunction with macros. This also enables some language-specific warnings described in C++ Dialect Options and Objective-C and Objective-C++ Dialect Options. Note; a bunch of -W options has the sentence This warning is enabled by -Wall. But there are a few that doesn't, but they are in the All of the above list. Perhaps the description for -Wall shouldn't include All of the above '-W' options combined. Or move the descriptions that doesn't include the This warning is enabled by -Wall below the -Wall description. It is confusing to read All of the above when it doesn't mean all of the above. --jc
Re: -Wswitch-enum and -Wswitch-default
On 02/04/07, Ching, Jimen (US SSA) [EMAIL PROTECTED] wrote: Therefore, only -Wswitch is enabled by -Wall but neither of Wswitch-default or Wswitch-enum are. Note; a bunch of -W options has the sentence This warning is enabled by -Wall. But there are a few that doesn't, but they are in the All of the above list. Perhaps the description for -Wall shouldn't include All of the above '-W' options combined. Or move the descriptions that doesn't include the This warning is enabled by -Wall below the -Wall description. No, it shouldn't. I think it should include just a list of options enabled by it á la -O1, -O2, etc. It is confusing to read All of the above when it doesn't mean all of the above. You are completely right. Cheers, Manuel.
Re: -Wswitch-enum and -Wswitch-default
On Mon, Apr 02, 2007 at 09:34:39PM +0100, Manuel López-Ibáñez wrote: On 02/04/07, Ching, Jimen (US SSA) [EMAIL PROTECTED] wrote: Therefore, only -Wswitch is enabled by -Wall but neither of Wswitch-default or Wswitch-enum are. Note; a bunch of -W options has the sentence This warning is enabled by -Wall. But there are a few that doesn't, but they are in the All of the above list. Perhaps the description for -Wall shouldn't include All of the above '-W' options combined. Or move the descriptions that doesn't include the This warning is enabled by -Wall below the -Wall description. No, it shouldn't. I think it should include just a list of options enabled by it á la -O1, -O2, etc. It is confusing to read All of the above when it doesn't mean all of the above. You are completely right. If there are any options listed above -Wall that are not enabled by -Wall, then this is a bug in the manual.
RFC: Enable __declspec for Linux/x86
Many x86 SSE source codes use __declspec. I'd like to make __declspec available for Linux/x86. We can do one of the following: 1. Define TARGET_DECLSPEC for Linux/x86. 2. Define TARGET_DECLSPEC for x86. 3. Add -mdeclspec. Any comments? H.J.
Re: RFC: Enable __declspec for Linux/x86
On 4/2/07, H. J. Lu [EMAIL PROTECTED] wrote: Many x86 SSE source codes use __declspec. I'd like to make __declspec available for Linux/x86. We can do one of the following: Do the following in the sources: #ifndef __WIN32__ #define __declspec(x) #endif or in the makefiles: Add -D__declspec(x)= to CFLAGS/CXXFLAGS. There is nothing special that __declspec does for Linux really. -- Pinski
Re: RFC: Enable __declspec for Linux/x86
On Mon, Apr 02, 2007 at 02:06:15PM -0700, Andrew Pinski wrote: On 4/2/07, H. J. Lu [EMAIL PROTECTED] wrote: Many x86 SSE source codes use __declspec. I'd like to make __declspec available for Linux/x86. We can do one of the following: Do the following in the sources: #ifndef __WIN32__ #define __declspec(x) #endif or in the makefiles: Add -D__declspec(x)= to CFLAGS/CXXFLAGS. It won't work with __declspec(align(16)) double x [4]; H.J.
Re: RFC: Enable __declspec for Linux/x86
On 4/2/07, H. J. Lu [EMAIL PROTECTED] wrote: It won't work with __declspec(align(16)) double x [4]; And the code should be converted over to use GCC style attributes. So really the code should be something like: #ifndef __WIN32__ #define __align16 __attribute__((align(16) )) #else #define __align16 __declspec(align(16) ) #endif And then use __align16 all the way through the code. There is no reason why GCC on Linux should be emulating MS's compiler. -- Pinski
Re: RFC: Enable __declspec for Linux/x86
On Apr 2, 2007, at 2:03 PM, H. J. Lu wrote: Many x86 SSE source codes use __declspec. I'd like to make __declspec available for Linux/x86. We can do one of the following: 1. Define TARGET_DECLSPEC for Linux/x86. 2. Define TARGET_DECLSPEC for x86. 3. Add -mdeclspec. Any comments? I suspect I'd want this for x86 darwin as well.
Re: RFC: Enable __declspec for Linux/x86
On 4/2/07, Mike Stump [EMAIL PROTECTED] wrote: I suspect I'd want this for x86 darwin as well. Why emulate Windows compilers on non windows machine? That is wrong. GCC for Linux/Darwin/any other OS besides Windows is not a Windows compiler and should not act like one. If people want to port their code, they should write their code to be portable way instead of depending on Windows or GCC stuff. -- Pinski
Re: RFC: Enable __declspec for Linux/x86
On 4/2/07, Andrew Pinski [EMAIL PROTECTED] wrote: Why emulate Windows compilers on non windows machine? That is wrong. GCC for Linux/Darwin/any other OS besides Windows is not a Windows compiler and should not act like one. If people want to port their code, they should write their code to be portable way instead of depending on Windows or GCC stuff. I should make a mention this is most likely for the Cell (for both sides PPC and SPU), we actually define and document a way to do aligned on variables (yes using GCC's attribute syntax) but this documentation is generic to all compiler implementations and they have to follow it. I have not seen a documentation from Intel about this or really any other intrinsics to explain how they are defined. I wish Intel gets the message here and actually documents the intrinsics and syntax, etc. for their vector extensions. -- Pinski
Re: RFC: Enable __declspec for Linux/x86
On 4/2/07, Andrew Pinski [EMAIL PROTECTED] wrote: On 4/2/07, Mike Stump [EMAIL PROTECTED] wrote: I suspect I'd want this for x86 darwin as well. Why emulate Windows compilers on non windows machine? That is wrong. GCC for Linux/Darwin/any other OS besides Windows is not a Windows compiler and should not act like one. If people want to port their code, they should write their code to be portable way instead of depending on Windows or GCC stuff. And what if whatever declspec is (I don't know) actually makes sense? Don't be Windows is not 42. Gr. Steven
Re: VAX backend status
Matt Thomas wrote: For instance, gcc emits: movab rpb,%r0 movab 100(%r0),%r1 cvtwl (%r1),%r0 but the movab 100(%r0),%r1 is completely unneeded, this should have been emitted as: movab rpb,%r0 cvtwl 100(%r0),%r0 Ah ! A clear case of all the world's a RISC syndrome. -- Toon Moene - e-mail: [EMAIL PROTECTED] - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.indiv.nluug.nl/~toon/ Who's working on GNU Fortran: http://gcc.gnu.org/ml/gcc/2007-01/msg00059.html
gcc-4.1-20070402 is now available
Snapshot gcc-4.1-20070402 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20070402/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.1 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_1-branch revision 123435 You'll find: gcc-4.1-20070402.tar.bz2 Complete GCC (includes all of below) gcc-core-4.1-20070402.tar.bz2 C front end and core compiler gcc-ada-4.1-20070402.tar.bz2 Ada front end and runtime gcc-fortran-4.1-20070402.tar.bz2 Fortran front end and runtime gcc-g++-4.1-20070402.tar.bz2 C++ front end and runtime gcc-java-4.1-20070402.tar.bz2 Java front end and runtime gcc-objc-4.1-20070402.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.1-20070402.tar.bz2The GCC testsuite Diffs from 4.1-20070326 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.1 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: VAX backend status
On 4/2/07, Toon Moene [EMAIL PROTECTED] wrote: Ah ! A clear case of all the world's a RISC syndrome. Actually I think it is a case of CSE/frowprop not doing the correct thing for the addressing modes. So it might be the real problem is the back-end's addressing mode cost are incorrect or just not doing anything. I really think you should debug this better and start with 4.3.0 with frowprop being there which does so much better with addressing modes. -- Pinski
Questions/Comments regarding my SoC application
Hi! I've applied for Google's Summer of Code 2007 with GCC as mentor organization. I want to make GCC working faster on the algorithmic level. I left out the detailed aims of the project, since i want to discuss them with gcc developers/mentors first. Do you have any suggestions what I should do? Are there any slow algorithms that should be replaced with high priority? Or shall i pick out the goals myself. But then I cannot estimate the expected time for finishing that project, I think you have a better overview in this case... I hope you can help me! Thx a lot, Dennis
Re: RFC: Enable __declspec for Linux/x86
On Mon, Apr 02, 2007 at 11:26:16PM +0200, Steven Bosscher wrote: On 4/2/07, Andrew Pinski [EMAIL PROTECTED] wrote: On 4/2/07, Mike Stump [EMAIL PROTECTED] wrote: I suspect I'd want this for x86 darwin as well. Why emulate Windows compilers on non windows machine? That is wrong. GCC for Linux/Darwin/any other OS besides Windows is not a Windows compiler and should not act like one. If people want to port their code, they should write their code to be portable way instead of depending on Windows or GCC stuff. And what if whatever declspec is (I don't know) actually makes sense? Don't be Windows is not 42. If the Windows version of GCC has to recognize __declspec to function as a hosted compiler on Windows, then the work already needs to be done to implement it. So what's the harm in allowing it on other platforms? If it makes it easier for Windows programmers to move to free compilers and OSes, isn't that something that should be supported?
Re: RFC: Enable __declspec for Linux/x86
On 4/2/07, Joe Buck [EMAIL PROTECTED] wrote: If the Windows version of GCC has to recognize __declspec to function as a hosted compiler on Windows, then the work already needs to be done to implement it. So what's the harm in allowing it on other platforms? If it makes it easier for Windows programmers to move to free compilers and OSes, isn't that something that should be supported? The only problem is that we have to be bug compatiable with all __declspec issues and having no documentation is going to make this harder. This is why Intel/AMD really should define a real language extension documentation for programming for SSE. -- Pinski
Re: RFC: Enable __declspec for Linux/x86
On Mon, Apr 02, 2007 at 03:11:06PM -0700, Andrew Pinski wrote: On 4/2/07, Joe Buck [EMAIL PROTECTED] wrote: If the Windows version of GCC has to recognize __declspec to function as a hosted compiler on Windows, then the work already needs to be done to implement it. So what's the harm in allowing it on other platforms? If it makes it easier for Windows programmers to move to free compilers and OSes, isn't that something that should be supported? The only problem is that we have to be bug compatiable with all __declspec issues and having no documentation is going to make this harder. This is why Intel/AMD really should define a real language extension documentation for programming for SSE. I believe __declspec in Intel C++ compiler comes from: http://msdn2.microsoft.com/en-us/library/dabb5z75.aspx H.J.
Re: x86-64 -mcx16, picky __sync_val_compare_and_swap?
On 4/2/07, Richard Henderson [EMAIL PROTECTED] wrote: On Mon, Apr 02, 2007 at 04:23:21PM +0200, tbp wrote: Am i just wrong believing that ought to work? Yes. It's hard to argue with a terse compiler or maintainer. Perhaps i should have picked an easier target like http://gcc.gnu.org/onlinedocs/gcc/Atomic-Builtins.html: GCC will allow any integral scalar or pointer type that is 1, 2, 4 or 8 bytes in length of which that TItype from the testsuite testcase is not. In any case thanks for the clarification.
Re: RFC: Enable __declspec for Linux/x86
On 4/2/07, H. J. Lu [EMAIL PROTECTED] wrote: I believe __declspec in Intel C++ compiler comes from: http://msdn2.microsoft.com/en-us/library/dabb5z75.aspx How is Microsoft documentation, the real documentation for Intel C++ compiler? Have you seen the Cell language extension document [1]? We document everything that is needed to be supported where does Intel/AMD document those? I have not seen a document like that for SSE/3DNow programming at all. In your patch, you forgot to document that you now accept __declspec for all x86 targets and the extra attribute you now accept there. The documentation for align attribute should have in bold this is only for __declspec. You should also mention what __declspecs are supported because right now you don't mention anything. [1] http://www-306.ibm.com/chips/techlib/techlib.nsf/techdocs/30B3520C93F437AB87257060006FFE5E or http://cell.scei.co.jp/pdf/Language_Extensions_for_CBEA_v23.pdf -- Pinski
Re: x86-64 -mcx16, picky __sync_val_compare_and_swap?
On Tue, Apr 03, 2007 at 01:54:16AM +0200, tbp wrote:
Am i just wrong believing that ought to work?
Yes.
It's hard to argue with a terse compiler or maintainer. Perhaps i
should have picked an easier target like
http://gcc.gnu.org/onlinedocs/gcc/Atomic-Builtins.html: GCC will
allow any integral scalar or pointer type that is 1, 2, 4 or 8 bytes
in length of which that TItype from the testsuite testcase is not.
But __m128{,i,d} is a vector type, and it doesn't apply.
r~
libcc_s.so and libc.so curcular dependency on FreeBSD
Hi, I am working on integrating GCC 4.1.x series into FreeBSD src/ tree. I've been running with the new compiler on FreeBSD 7.0 for quite a while now, but was hesitant to commit my changes because of a couple of unsolved issues. I would really appreciate your input on the way to overcome them. One of the main goals for the upcoming compiler refresh in FreeBSD was to start using shared libgcc_s.so.1, something we did not do before. Ideally I want libgcc_s.so.1 built from FreeBSD src/ tree to be 100% binary compatible with the library build from stock GCC sources as checked out from FSF SVN repository. This is where the first problem lies. libgcc_s.so.1 depends on libc.so.1 (and libpthread.so) for symbols like malloc, free, pthread_once, pthread_mutex_lock, etc. libc in turn depends on libgcc_s.so.1 due to the default way exception frame info information registration is implemented in FreeBSD. Each shared object is expected to issue calls to __register_frame_info and __deregister_frame_info in its startup/shutdown code in order for exception handlers to work across shared library boundaries. This creates a dependency cycle that I need to break. The simplest way to go appears to follow Linux's lead and eliminate the need for shared modules to have explicit frame into registration calls at startup and allow exception handling code to locate necessary info with the help of dynamic loader using dl_iterate_phdr call. I went ahead and implemented necessary code in FreeBSD's ld-elf.so.1 and with little changes in gcc crtstuff.c and unwind-dw2-fde-glibc.c I was able to get things working. I did not find any breakage yet and everything seems to run smoothly so far. I wonder if you could confirm that this is a good resolution for the circular dependency issue or is there a better way. Since both libc and libgcc_s will both have symbol version support turned on on them, I cannot import the new compiler into FreeBSD until this dilemma is solved in one way or another. I also noticed that on Linux glibc implements some of the libgcc symbols, namely _Unwind_Find_FDE and __register_frame_info_bases family of functions. I wonder why it is done and if I missed something obvious here. I wonder if GCC team will be willing to accept gcc part of my changes into mainstream sources if I submit a patch. What are chances of something like this to be committed into not only trunk, but also GCC 4.1, 4.2 and 4.3 branches? FreeBSD 7.0 wants to ship with GCC 4.1, but newer version is likely to be imported into trunk shortly after CVS is branched for 7.0 release. All I had to do is to extend checks for GLIBC 2.2.4 in above mentioned GCC files to also check for suitable __FreeBSD_version__ and they compile just fine. I also had to add Linux-compatible definition for struct dl_phdr_info along with dl_iterate_phdr function prototype into FreeBSD's link.h header file. -- Alexander Kabaev signature.asc Description: PGP signature
[Bug libfortran/31052] [4.2 only] Bad IOSTAT values when readings NAMELISTs past EOF
--- Comment #41 from anlauf at gmx dot de 2007-04-02 08:42 --- (In reply to comment #40) New Revision: 123404 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123404 Log: 2007-04-01 Jerry DeLisle [EMAIL PROTECTED] Jerry, thanks so far, but now I am back to the situation described in comment #23. I will try to produce a new reduced testcase that leads to this crash in the next days. I'd like to ask you to keep this PR open for a few more days until we know whether the other problem is related or unrelated to this PR. Thanks, -ha -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31052
[Bug fortran/31424] New: ICE involving transfer function, and passing function return to subroutine
I get the following ICE: test.f90: In function MAIN__: test.f90:29: internal compiler error: in gfc_get_symbol_decl, at fortran/trans-decl.c:877 Please submit a full bug report, when compiling this code: module InternalCompilerError type Byte private character(len=1) :: singleByte end type type (Byte) :: BytesPrototype(1) type UserType real :: r end type contains function UserTypeToBytes(user) result (bytes) type(UserType) :: user type(Byte) :: bytes(size(transfer(user, BytesPrototype))) bytes = transfer(user, BytesPrototype) end function subroutine DoSomethingWithBytes(bytes) type(Byte), intent(in) :: bytes(:) end subroutine end module program main use InternalCompilerError type (UserType) :: user ! The following line causes the ICE call DoSomethingWithBytes( UserTypeToBytes(user) ) end program As indicated in the comments, the ICE is caused by the line passing a function result to a subroutine. Kind regards, Drew -- Summary: ICE involving transfer function, and passing function return to subroutine Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: drewmccormack at mac dot com GCC build triplet: gcc version 4.3.0 20070325 (experimental) GCC target triplet: powerpc-apple-darwin8 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31424
Re: gcc-3.4.6 and sh-unknown-linux-gnu build error
Motohisa Moriya wrote: -#if defined (__SH3E__) || defined (__SH4__) +#if defined (__SH4E__) || defined (__SH4__) There's no such thing as an SH4E. There is an SH3E and it shares the same single-precision support as SH4, thus there are some places where I would expect to see such an #if. I don't understand what your problem really is, but it isn't what you think it is. Andrew
[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L
--- Comment #65 from bkoz at redhat dot com 2007-04-02 09:49 --- Subject: Re: __cplusplus defined to 1, should be 199711L Weird, when solaris is the easiest one. That's certainly a matter of perspective. Based on Solaris 11 x86, I don't see a way for say cstdlib to have only the namespace std versions of functions, and not also the global scoped ones. #include iso/stdlib_iso.h (this is how sun studio compiler does it) If you also want the C99 functions, then you have to wait for the next c++ standard to actually exist before solaris changes its headers accordingly. Ah. Thanks for pointing this out to me. Figuring out how to map these files correctly just for solaris will be interesting. My RFC message about C++0x headers had the details on my implementation plan, I think. Sorry for the dumb question, but where is it? Sorry, I cannot find this at the moment. The plan is to correct the includes/c implementation. -benjamin -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1773
RE: gcc-3.4.6 and sh-unknown-linux-gnu build error
Andrew STUBBS wrote: There's no such thing as an SH4E. There is an SH3E and it shares the same single-precision support as SH4, thus there are some places where I would expect to see such an #if. It is said that the libgcc.a multi-library cannot be made because an impossible register is referred for SH3 if I say easily. It is said that it makes an error of making the multi library in sh-unknown-linux-gnu on the way so that the register definition of 2.4 factions Linux may refer to an impossible combination for this because define is done with SH4E and SH4. Therefore, if this patch is put away without recapitulating as -- target=sh-unknown-linux-gnu, it is sure to become an error. The header file was made here based on crosstools 0.84, and it succeeded in making of all libraries since it had it of seeing the header file. It ..said extent alone.. is not thought that the SH architecture can be basic in my understanding big endian and set little endian to the end. Endian is not seen on the linux side but the SH3 architecture or the SH4 architecture is not passed though the register for SH4 is referred when the header file on the linux side sees the register of SH4 ..seeing... At least, only refer to SH4E SH4 when you see the register added with SH4 on the linux side.
[Bug c++/31164] Problem with GCC 4.1 and Boost signals
--- Comment #4 from pluto at agmk dot net 2007-04-02 10:13 --- attached testcase works fine with vs2k3/boost-1.33/stlport. it also works with g++-4.0.0/20050519(RH 4.0.0-8)/boost/libstdc++ on x86_64-gnu-linux. in the other. indeed, it fails with 4.1.2 and 4.2.0 (4.3 not tested). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31164
Re: gcc-3.4.6 and sh-unknown-linux-gnu build error
Motohisa Moriya wrote: Andrew STUBBS wrote: There's no such thing as an SH4E. There is an SH3E and it shares the same single-precision support as SH4, thus there are some places where I would expect to see such an #if. It is said that the libgcc.a multi-library cannot be made because an impossible register is referred for SH3 if I say easily. It is said that it makes an error of making the multi library in sh-unknown-linux-gnu on the way so that the register definition of 2.4 factions Linux may refer to an impossible combination for this because define is done with SH4E and SH4. Therefore, if this patch is put away without recapitulating as -- target=sh-unknown-linux-gnu, it is sure to become an error. The header file was made here based on crosstools 0.84, and it succeeded in making of all libraries since it had it of seeing the header file. It ..said extent alone.. is not thought that the SH architecture can be basic in my understanding big endian and set little endian to the end. Endian is not seen on the linux side but the SH3 architecture or the SH4 architecture is not passed though the register for SH4 is referred when the header file on the linux side sees the register of SH4 ..seeing... At least, only refer to SH4E SH4 when you see the register added with SH4 on the linux side. Sorry, I find this very hard to read. I think you found it very hard to write. :) I do not say that the code is right. I say that changing SH3E to SH4E is wrong. It might be that completely removing SH3E is right. Perhaps the error is somewhere else. Kaz, I don't know if you have already seen this message. Perhaps you can help Motohisa, both with the compiler and the language barrier? Andrew
[Bug libstdc++/31413] FAIL: 22_locale/time_get/get_date/wchar_t/4.cc execution test
--- Comment #11 from pcarlini at suse dot de 2007-04-02 10:32 --- Ok, therefore we cannot consider anymore the issue a libstdc++ issue. -- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31413
[Bug libstdc++/31401] string find behaves strange when searching from npos
--- Comment #5 from paolo at gcc dot gnu dot org 2007-04-02 11:09 --- Subject: Bug 31401 Author: paolo Date: Mon Apr 2 11:08:50 2007 New Revision: 123422 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123422 Log: 2007-04-02 Paolo Carlini [EMAIL PROTECTED] PR libstdc++/31401 (vstring bits) * include/ext/vstring.tcc (find(const _CharT*, size_type, size_type)): Avoid unsigned overflow. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/ext/vstring.tcc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31401
[Bug libstdc++/31401] string find behaves strange when searching from npos
--- Comment #6 from paolo at gcc dot gnu dot org 2007-04-02 11:09 --- Subject: Bug 31401 Author: paolo Date: Mon Apr 2 11:09:07 2007 New Revision: 123423 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123423 Log: 2007-04-02 Paolo Carlini [EMAIL PROTECTED] PR libstdc++/31401 (vstring bits) * include/ext/vstring.tcc (find(const _CharT*, size_type, size_type)): Avoid unsigned overflow. Modified: branches/gcc-4_2-branch/libstdc++-v3/ChangeLog branches/gcc-4_2-branch/libstdc++-v3/include/ext/vstring.tcc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31401
[Bug libstdc++/31370] resizing bugs in std::vectorbool
--- Comment #9 from paolo at gcc dot gnu dot org 2007-04-02 11:16 --- Subject: Bug 31370 Author: paolo Date: Mon Apr 2 11:15:50 2007 New Revision: 123424 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123424 Log: 2007-04-02 Matthew Levine [EMAIL PROTECTED] Paolo Carlini [EMAIL PROTECTED] PR libstdc++/31370 * include/bits/stl_bvector.h (vectorbool::max_size): Fix. (vectorbool::_M_check_len): Add. * include/bits/vector.tcc (_M_fill_insert(iterator, size_type, bool), _M_insert_range(iterator, _ForwardIterator, _ForwardIterator, std::forward_iterator_tag), _M_insert_aux(iterator, bool)): Use it. * testsuite/23_containers/vector/bool/modifiers/insert/31370.cc: New. * testsuite/23_containers/vector/bool/capacity/29134.cc: Adjust. * include/bits/stl_vector.h (vector::_M_check_len): Add. * include/bits/vector.tcc (_M_insert_aux(iterator, const _Tp), _M_fill_insert(iterator, size_type, const value_type), _M_range_insert(iterator, _ForwardIterator, _ForwardIterator, std::forward_iterator_tag)): Use it. Added: trunk/libstdc++-v3/testsuite/23_containers/vector/bool/modifiers/insert/31370.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/stl_bvector.h trunk/libstdc++-v3/include/bits/stl_vector.h trunk/libstdc++-v3/include/bits/vector.tcc trunk/libstdc++-v3/testsuite/23_containers/vector/bool/capacity/29134.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31370
[Bug libstdc++/31370] resizing bugs in std::vectorbool
--- Comment #10 from pcarlini at suse dot de 2007-04-02 11:19 --- Fixed for 4.3.0. -- pcarlini at suse dot de changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31370
[Bug fortran/31424] ICE involving transfer function, and passing function return to subroutine
--- Comment #1 from pault at gcc dot gnu dot org 2007-04-02 11:33 --- (In reply to comment #0) As indicated in the comments, the ICE is caused by the line passing a function Sort of: In order to find out the size of the function result, gfortran evaluates transfer(user, BytesPrototype). Since BytesPrototype is not referenced in the main program, the ICE Results. Strangely, if we do reference BytesPrototype in MAIN, the program compiles but segfaults at run-time. This appears to be a double bug:) A workaround that is neat and gives the correct result is: module InternalCompilerError type Byte private integer(1) :: singleByte end type type (Byte) :: BytesPrototype(1) type UserType real :: r end type contains function UserTypeToBytes(user) result (bytes) type(UserType) :: user type(Byte) :: bytes(size_of_user (user)) bytes = transfer(user, BytesPrototype) end function subroutine DoSomethingWithBytes(bytes) type(Byte), intent(in) :: bytes(:) print *, bytes end subroutine pure integer function size_of_user ( arg ) type(UserType), intent(in) :: arg size_of_user = size(transfer(arg, BytesPrototype)) end function size_of_user end module program main use InternalCompilerError type (UserType) :: user = UserType (1.0) ! The following line causes the ICE call DoSomethingWithBytes( UserTypeToBytes(user) ) end program Thanks for the report Paul Thomas -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-04-02 11:33:38 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31424
RE: gcc-3.4.6 and sh-unknown-linux-gnu build error
Andrew STUBBS wrote: Sorry, I find this very hard to read. I think you found it very hard to write. :) I do not say that the code is right. I say that changing SH3E to SH4E is wrong. It might be that completely removing SH3E is right. Perhaps the error is somewhere else. Kaz, I don't know if you have already seen this message. Perhaps you can help Motohisa, both with the compiler and the language barrier? Sorry. I am not good at English. I do not think that it is correct to detach SH3E. I transplanted linux to TMM-1000 and TMM-1200. I am wishing that all of SH2,SH2E, SH3, SH3E, SH4, and SH4E can be compiled with sh-unknown-linux-gnu-gcc. Sorry Mr. Kojima.
Re: gcc-3.4.6 and sh-unknown-linux-gnu build error
Motohisa Moriya wrote: I am wishing that all of SH2,SH2E, SH3, SH3E, SH4, and SH4E can be compiled with sh-unknown-linux-gnu-gcc. SH4E does not exist. Perhaps you mean SH4A?
[Bug fortran/31424] ICE involving transfer function, and passing function return to subroutine
--- Comment #2 from pault at gcc dot gnu dot org 2007-04-02 12:51 --- To my amazement, the brute force: Index: gcc/fortran/trans-decl.c === *** gcc/fortran/trans-decl.c(révision 122688) --- gcc/fortran/trans-decl.c(copie de travail) *** gfc_get_symbol_decl (gfc_symbol * sym) *** 874,879 --- 874,880 int byref; gcc_assert (sym-attr.referenced +|| sym-attr.use_assoc || sym-ns-proc_name-attr.if_source == IFSRC_IFBODY); if (sym-ns sym-ns-proc_name-attr.function) fixes the problem. I have just set it regtesting. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31424
[Bug libf2c/31425] New: gcc 3.4.6 and gcc 4.1.2 on HP 11.23 Itinium (ia64)URGENT
Hi All, I am trying to compile cfengine. I was using gcc version 4.0.2 and was facing an error. I found that the my problem is due to a bug that has been fixed and in version 4.1 onwards. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26189 I rebuild it with gcc version 4.1.2 (binary available on http://hpux.connect.org.uk/) I recompiled, however the issue didnt go off.. -- I decided to build a lower version of gcc . Was able to build gcc-3.4.6 with gnu binutils-2.14., flex and bison(latest GNU versions). My machine does'nt have yacc or lex. I ensured i have gnu make (2.18)too. I got a Warning message while compiling this gcc version as gcc -g -O2 -Wreturn-type -Wmissing-prototypes -Wuninitialized -D_REENTRANT -pthread -g -O2 -I/home/soetest1/cfengine/db-install/include -D_REENTRANT -pthread -g -O2 -I/home/soetest1/cfengine/db-install/include -L/home/soetest1/cfengine/db-install/lib -L/home/soetest1/cfengine/openssl-install/lib -L/opt/dce/lib -L/opt/dce/lib -o cfshow cfshow.o globals.o popen.o log.o errors.o filenames.o patches.o -ll -ll -ldb -lcrypto -L../pub -lpub -lpthread -lm -lc ld: (Warning) Unsatisfied symbol yyleng in file /usr/lib/hpux32/libl.so ld: (Warning) Unsatisfied symbol yylenguc in file /usr/lib/hpux32/libl.so ld: (Warning) Unsatisfied symbol yyinput in file /usr/lib/hpux32/libl.so ld: (Warning) Unsatisfied symbol yyunput in file /usr/lib/hpux32/libl.so ld: (Warning) Unsatisfied symbol yyolsp in file /usr/lib/hpux32/libl.so ld: (Warning) Unsatisfied symbol yytext in file /usr/lib/hpux32/libl.so ld: (Warning) Unsatisfied symbol yyoutput in file /usr/lib/hpux32/libl.so ld: (Warning) Unsatisfied symbol yytextuc in file /usr/lib/hpux32/libl.so ld: (Warning) Unsatisfied symbol yyextra in file /usr/lib/hpux32/libl.so ld: (Warning) Unsatisfied symbol yyfnd in file /usr/lib/hpux32/libl.so ld: (Warning) Unsatisfied symbol yyprevious in file /usr/lib/hpux32/libl.so ld: (Warning) Unsatisfied symbol yylex in file /usr/lib/hpux32/libl.so ld: (Warning) Unsatisfied symbol yylsp in file /usr/lib/hpux32/libl.so ld: (Warning) Unsatisfied symbol yyout in file /usr/lib/hpux32/libl.so ld: (Warning) Unsatisfied symbol yylstate in file /usr/lib/hpux32/libl.so ld: (Warning) Unsatisfied symbol yytextarr in file /usr/lib/hpux32/libl.so ld: (Warning) Unsatisfied symbol yyback in file /usr/lib/hpux32/libl.so 17 warnings. -- I was able to compile cfengine with above however the binaries do not seem to work and give me same error. # /opt/soe/local/soe_cfengine/sbin/cfagent /usr/lib/hpux32/dld.so: Unsatisfied data symbol 'yylsp' in load module '/usr/lib/hpux32/libl.so.1'. /usr/lib/hpux32/dld.so: Unsatisfied data symbol 'yyolsp' in load module '/usr/lib/hpux32/libl.so.1'. /usr/lib/hpux32/dld.so: Unsatisfied data symbol 'yyfnd' in load module '/usr/lib/hpux32/libl.so.1'. /usr/lib/hpux32/dld.so: Unsatisfied data symbol 'yytextuc' in load module '/usr/lib/hpux32/libl.so.1'. /usr/lib/hpux32/dld.so: Unsatisfied data symbol 'yylenguc' in load module '/usr/lib/hpux32/libl.so.1'. /usr/lib/hpux32/dld.so: Unsatisfied data symbol 'yylstate' in load module '/usr/lib/hpux32/libl.so.1'. /usr/lib/hpux32/dld.so: Unsatisfied data symbol 'yyprevious' in load module '/usr/lib/hpux32/libl.so.1'. /usr/lib/hpux32/dld.so: Unsatisfied data symbol 'yytextarr' in load module '/usr/lib/hpux32/libl.so.1'. /usr/lib/hpux32/dld.so: Unsatisfied data symbol 'yyextra' in load module '/usr/lib/hpux32/libl.so.1'. Killed I noticed there is another bug raised and fixed in gcc version 3.4. 3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24718 However it should not give me any issue with 3.4.6. why am I getting the same error? Please advice? Neetee -- Summary: gcc 3.4.6 and gcc 4.1.2 on HP 11.23 Itinium (ia64)URGENT Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libf2c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: npawa at csc dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31425
RE: gcc-3.4.6 and sh-unknown-linux-gnu build error
Andrew STUBBS wrote: Perhaps you mean SH4A? yes Because my debian environment has crashed, -m option cannot be confirmed Please point it out if the mistake is found in my idea. SH2A Core SH2,SH3 SH4A Core SH4 (SH5 is unknown) Motohisa
Re: gcc-3.4.6 and sh-unknown-linux-gnu build error
Hi Andrew, Andrew STUBBS [EMAIL PROTECTED] wrote: I do not say that the code is right. I say that changing SH3E to SH4E is wrong. It might be that completely removing SH3E is right. Perhaps the error is somewhere else. Kaz, I don't know if you have already seen this message. Perhaps you can help Motohisa, both with the compiler and the language barrier? I've missed it. Moriya-san, could you write your real problem in japanese to me. Regards, kaz
[Bug libfortran/31052] [4.2 only] Bad IOSTAT values when readings NAMELISTs past EOF
--- Comment #42 from jvdelisle at gcc dot gnu dot org 2007-04-02 14:35 --- Will keep open until we get them all!. Looks like I need another test case. :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31052
[Bug fortran/31213] ICE on valid code with gfortran
--- Comment #3 from pault at gcc dot gnu dot org 2007-04-02 14:43 --- (In reply to comment #2) an ICE in the same place, but it appears it isn't fixed. Paul, since the previous PRs were really related, you might understand this one easily? I had hoped so, but the problem here turns out to be in resolution. I can fix the reduced testcase but the original is still eluding me. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31213
[Bug middle-end/30704] [4.2/4.3 Regression] Incorrect constant generation for long long
-- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2007-02-05 19:43:22 |2007-04-02 14:58:41 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30704
[Bug libstdc++/31426] New: TR1 includes do not work with -std=c++0x
When the compiler is provided with -std=c++0x to enable the experimental C++0x
mode, includes of TR1 facilities (e.g., tr1/tuple) do not put TR1 functionality
into namespace std::tr1, breaking backward compatibility. Here's an example
program that compiles without -std=c++0x but does not compile with it:
#include tr1/tuple
int main()
{
std::tr1::tupleint, double x(17, 3.14);
return 0;
}
--
Summary: TR1 includes do not work with -std=c++0x
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dgregor at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31426
[Bug target/31380] [4.1/4.2]: Typo in gcc/config/i386/sse.md
--- Comment #3 from hjl at gcc dot gnu dot org 2007-04-02 15:54 --- Subject: Bug 31380 Author: hjl Date: Mon Apr 2 15:53:48 2007 New Revision: 123428 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123428 Log: 2007-04-02 H.J. Lu [EMAIL PROTECTED] * Backport from mainline: 2007-03-28 Grigory Zagorodnev [EMAIL PROTECTED] PR target/31380 * config/i386/sse.md (uminv16qi3): Use UMIN instead of UMAX. Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/config/i386/sse.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31380
[Bug target/31380] [4.1/4.2]: Typo in gcc/config/i386/sse.md
--- Comment #4 from hjl at gcc dot gnu dot org 2007-04-02 15:55 --- Subject: Bug 31380 Author: hjl Date: Mon Apr 2 15:55:17 2007 New Revision: 123429 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123429 Log: 2007-04-02 H.J. Lu [EMAIL PROTECTED] * Backport from mainline: 2007-03-28 Grigory Zagorodnev [EMAIL PROTECTED] PR target/31380 * config/i386/sse.md (uminv16qi3): Use UMIN instead of UMAX. Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/config/i386/sse.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31380
[Bug target/31380] [4.1/4.2]: Typo in gcc/config/i386/sse.md
--- Comment #5 from hjl at lucon dot org 2007-04-02 15:57 --- Fixed in gcc 4.1.3 and 4.2.0. -- hjl at lucon dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.1.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31380
[Bug libstdc++/31426] TR1 includes do not work with -std=c++0x
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-04-02 16:18 --- isn't that a feature? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31426
[Bug rtl-optimization/323] optimized code gives strange floating point results
--- Comment #94 from bonzini at gnu dot org 2007-04-02 16:20 --- I think that Uros' patch to add a -mpc switch for precision control would fix this. The real fix would be to automatically insert fldcw instructions before float/double operations, in order to limit the precision of the operations. But I think that it would kill speed even more than -ffloat-store. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323
[Bug fortran/31114] Consistent floating point arithmetic model option
--- Comment #7 from bonzini at gnu dot org 2007-04-02 16:21 --- Reopened... -- bonzini at gnu dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31114
[Bug fortran/31114] Consistent floating point arithmetic model option
--- Comment #8 from bonzini at gnu dot org 2007-04-02 16:22 --- ... because GCC now has -mpc to limit precision for float/double operations. Even as far as x86 is concerned, this is a special case of PR323, and thus I'm closing it as fixed. -- bonzini at gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Known to work||4.3.0 Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31114
[Bug libstdc++/31426] TR1 includes do not work with -std=c++0x
--- Comment #2 from dgregor at gcc dot gnu dot org 2007-04-02 16:32 --- I don't think it is a feature. In C++0x mode, if one includes tuple, one should get std::tuple. That's what the C++0x working paper says. In any mode, if one includes tr1/tuple, one should get std::tr1::tuple. That's what TR1 says (well, TR1 might say that you get std::tr1::tuple from including tuple; different vendors have done different things, here). I don't think support for C++0x precludes support for TR1. They coexist very well, especially because TR1 was designed to be compatible with C++0x. For example, C++0x-conforming implementations of the TR1 facilities also meet the requirements of TR1. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31426
[Bug target/26792] [4.2 Regression] need to use autoconf when using newly-added libgcc functions
--- Comment #31 from sje at cup dot hp dot com 2007-04-02 16:36 --- When configuring with --with-system-libunwind, GCC should not include unwind-compat.o (or any unwind code) in the build of libgcc_s. Then the configure check will work correctly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26792
[Bug fortran/31293] Implicit character and array returning functions
--- Comment #2 from pault at gcc dot gnu dot org 2007-04-02 16:38 ---
This fixes the problem and regtests:
Index: gcc/fortran/parse.c
===
*** gcc/fortran/parse.c (révision 123426)
--- gcc/fortran/parse.c (copie de travail)
*** static void
*** 2896,2901
--- 2896,2902
parse_progunit (gfc_statement st)
{
gfc_state_data *p;
+ gfc_symbol *proc = NULL;
int n;
st = parse_spec (st);
*** parse_progunit (gfc_statement st)
*** 2913,2918
--- 2914,2940
default:
break;
+ }
+
+ proc = gfc_current_ns-proc_name;
+ if (gfc_current_state () == COMP_FUNCTION
+proc-attr.contained
+(proc-attr.implicit_type
+ || proc-result-ts.type == BT_UNKNOWN))
+ {
+ if (gfc_set_default_type (proc-result, 0, gfc_current_ns)
+ == SUCCESS)
+ {
+ if (proc-result != proc)
+ proc-ts = proc-result-ts;
+ }
+ else
+ {
+ gfc_error (unable to implicitly type the function result
+'%s' at %L, proc-result-name,
+proc-result-declared_at);
+ proc-result-attr.untyped = 1;
+ }
}
loop:
It has the same behaviour as LF95, in respect of interface1.f90 - ie. no errors
or warnings, in respect of explcit typing being needed for the function. This
is just a matter of getting the condition right.
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org
|dot org |
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2007-04-02 16:38:36
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31293
[Bug c++/31423] Improve upon invalid use of member (did you forget the '' ?)
--- Comment #1 from bangerth at dealii dot org 2007-04-02 17:09 --- Confirmed. W. -- bangerth at dealii dot org changed: What|Removed |Added CC||bangerth at dealii dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-04-02 17:09:15 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31423
[Bug libstdc++/31426] TR1 includes do not work with -std=c++0x
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-04-02 17:26 --- Ah, I see. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-04-02 17:26:11 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31426
[Bug preprocessor/29851] Need to strip trailing slashes on include pathnames
--- Comment #3 from eweddington at cso dot atmel dot com 2007-04-02 17:41 --- Can someone please commit this patch? I need this for mingw-hosted cross toolchains. -- eweddington at cso dot atmel dot com changed: What|Removed |Added CC||eweddington at cso dot atmel ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29851
[Bug fortran/31067] MINLOC should sometimes be inlined (gas_dyn is sooooo sloooow)
--- Comment #14 from tkoenig at gcc dot gnu dot org 2007-04-02 17:44 --- I'll give this another shot. Maybe inlining isn't even necessary for good performance... -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tkoenig at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-03-07 21:09:53 |2007-04-02 17:44:28 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31067
[Bug fortran/31427] New: When I compile the following program I get the message GNU MP: Cannot reallocate memory
When I compile the following program I get the message GNU MP: Cannot reallocate memory PROGRAM test INTEGER(KIND=1) :: i(1) i = (/ TRANSFER(a, 0) /) END PROGRAM test -- Summary: When I compile the following program I get the message GNU MP: Cannot reallocate memory Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: michael dot a dot richmond at nasa dot gov http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31427
[Bug c++/31187] [4.2/4.3 regression] extern declaration of variable in anonymous namespace prevents use of its address as template argument
--- Comment #7 from jason at gcc dot gnu dot org 2007-04-02 18:49 --- Subject: Bug 31187 Author: jason Date: Mon Apr 2 18:49:21 2007 New Revision: 123432 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123432 Log: PR c++/31187 * typeck.c (cp_type_readonly): New fn. * cp-tree.h: Declare it. * decl.c (start_decl): Set implicit DECL_THIS_STATIC here. (cp_finish_decl): Not here. * g++.dg/ext/visibility/anon3.C: New test. Added: trunk/gcc/testsuite/g++.dg/ext/visibility/anon3.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.h trunk/gcc/cp/decl.c trunk/gcc/cp/typeck.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31187
[Bug fortran/31428] New: When I compile the following program I get the message GNU MP: Cannot reallocate memory
When I compile the following program I get the message GNU MP: Cannot reallocate memory PROGRAM test INTEGER(KIND=1) :: i(1) i = (/ TRANSFER(a, 0) /) END PROGRAM test -- Summary: When I compile the following program I get the message GNU MP: Cannot reallocate memory Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: michael dot a dot richmond at nasa dot gov http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31428
[Bug fortran/31427] When I compile the following program I get the message GNU MP: Cannot reallocate memory
--- Comment #1 from kargl at gcc dot gnu dot org 2007-04-02 19:06 --- *** Bug 31428 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31427
[Bug fortran/31428] When I compile the following program I get the message GNU MP: Cannot reallocate memory
--- Comment #1 from kargl at gcc dot gnu dot org 2007-04-02 19:06 --- *** This bug has been marked as a duplicate of 31427 *** -- kargl at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31428
[Bug c/31429] New: Is anybody monitoring the daily regression tests on Darwin 8.5?
-- Summary: Is anybody monitoring the daily regression tests on Darwin 8.5? Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dominiq at lps dot ens dot fr GCC target triplet: powerpc-apple-darwin7 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31429
[Bug c/31430] New: Is anybody monitoring the daily regression tests on Darwin 8.5?
(~100) of regressions: gcc.c-torture/execute/builtins/memcpy-chk.c, ..., gcc.c-torture/execute/built-in-setjmp.c. Looking at the list, I have found that this has started on 20070325 for Darwin8: http://gcc.gnu.org/ml/gcc-testresults/2007-03/msg01225.html Note that the errors are all of the following kind: output is: /var/tmp//cceFaqh1.s:2000:non-relocatable subtraction expression, L006$pb minus LSJR191 /var/tmp//cceFaqh1.s:2000:symbol: LSJR191 can't be undefined in a subtraction expression ... -- Summary: Is anybody monitoring the daily regression tests on Darwin 8.5? Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dominiq at lps dot ens dot fr GCC target triplet: powerpc-apple-darwin7 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31430
[Bug target/31429] [4.3 Regression] __builtin_setjmp/__builtin_longjmp is broken on ppc-darwin
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-04-02 20:05 --- This was caused by the conversion of l constaint to hard registers. I sent a patch to Andreas T. to test as I don't have an up todate sources on my ppc-darwin machine that I use to test patches. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Component|c |target Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-04-02 20:05:27 date|| Summary|Is anybody monitoring the |[4.3 Regression] |daily regression tests on |__builtin_setjmp/__builtin_l |Darwin 8.5? |ongjmp is broken on ppc- ||darwin Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31429
[Bug c/31430] Is anybody monitoring the daily regression tests on Darwin 8.5?
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-04-02 20:05 --- *** This bug has been marked as a duplicate of 31429 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31430
[Bug target/31429] [4.3 Regression] __builtin_setjmp/__builtin_longjmp is broken on ppc-darwin
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-04-02 20:05 --- *** Bug 31430 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31429
[Bug fortran/31427] When I compile the following program I get the message GNU MP: Cannot reallocate memory
--- Comment #2 from dfranke at gcc dot gnu dot org 2007-04-02 20:10 --- Can confirm a crash in f951. Since there were quite a lot of TRANSFER related reports lately, I can not tell if this a new one. Backtrace: Starting program: /home/daniel/i686-pc-linux-gnu/gcc/libexec/gcc/i686-pc-linux-gnu/4.3.0/f951 -g -Wall 31427.f90 Program received signal SIGSEGV, Segmentation fault. 0xb7f36571 in __gmpn_copyi () from /usr/lib/libgmp.so.3 (gdb) bt #0 0xb7f36571 in __gmpn_copyi () from /usr/lib/libgmp.so.3 #1 0xb7f238b4 in __gmpz_set () from /usr/lib/libgmp.so.3 #2 0x0804d9d6 in gfc_int2int (src=0x8894930, kind=1) at ../../../gcc/gcc/fortran/arith.c:2006 #3 0x0809b1dd in gfc_convert_constant (e=0x8894758, type=BT_INTEGER, kind=1) at ../../../gcc/gcc/fortran/simplify.c:4035 #4 0x08068134 in do_simplify (specific=0x888a3f8, e=0x8894898) at ../../../gcc/gcc/fortran/intrinsic.c:3112 #5 0x08068305 in gfc_convert_type_warn (expr=0x8894898, ts=0x88945ac, eflag=1, wflag=1) at ../../../gcc/gcc/fortran/intrinsic.c:3579 #6 0x08068578 in gfc_convert_type (expr=0x8894898, ts=0x88945ac, eflag=1) at ../../../gcc/gcc/fortran/intrinsic.c:3491 #7 0x0809633f in resolve_code (code=value optimized out, ns=0x885a1e8) at ../../../gcc/gcc/fortran/resolve.c:5163 #8 0x08097a24 in gfc_resolve (ns=0x885a1e8) at ../../../gcc/gcc/fortran/resolve.c:7343 #9 0x0808c0ca in gfc_parse_file () at ../../../gcc/gcc/fortran/parse.c:3245 #10 0x080ab660 in gfc_be_parse_file (set_yydebug=0) at ../../../gcc/gcc/fortran/f95-lang.c:305 #11 0x0830042d in toplev_main (argc=4, argv=0xbfd587f4) at ../../../gcc/gcc/toplev.c:1050 #12 0x080ed162 in main (argc=49, argv=0xa000) at ../../../gcc/gcc/main.c:35 -- dfranke at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||31237 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31427
[Bug c++/31187] [4.2/4.3 regression] extern declaration of variable in anonymous namespace prevents use of its address as template argument
--- Comment #8 from jason at gcc dot gnu dot org 2007-04-02 20:12 --- Subject: Bug 31187 Author: jason Date: Mon Apr 2 20:12:15 2007 New Revision: 123434 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123434 Log: PR c++/31187 * typeck.c (cp_type_readonly): New fn. * cp-tree.h: Declare it. * decl.c (start_decl): Set implicit DECL_THIS_STATIC here. (cp_finish_decl): Not here. * g++.dg/ext/visibility/anon3.C: New test. Added: branches/gcc-4_2-branch/gcc/testsuite/g++.dg/ext/visibility/anon3.C - copied unchanged from r123432, trunk/gcc/testsuite/g++.dg/ext/visibility/anon3.C Modified: branches/gcc-4_2-branch/gcc/cp/ChangeLog branches/gcc-4_2-branch/gcc/cp/cp-tree.h branches/gcc-4_2-branch/gcc/cp/decl.c branches/gcc-4_2-branch/gcc/cp/typeck.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31187
[Bug c++/31431] New: [4.3 regression] ICE with invalid parameter pack
The following (IMHO invalid) code snippet triggers an ICE on mainline:
===
templatetypename..., typename void foo();
void bar()
{
fooint();
}
===
bug.cc: In function 'void bar()':
bug.cc:5: internal compiler error: tree check: expected class 'expression',
have 'type' (integer_type) in fn_type_unification, at cp/pt.c:11058
Please submit a full bug report, [etc.]
The slightly modified version below triggers a segfault:
===
templatetypename, typename..., typename void foo();
void bar()
{
fooint();
}
===
bug.cc: In function 'void bar()':
bug.cc:5: internal compiler error: Segmentation fault
Please submit a full bug report, [etc.]
Doug, looks like fallout from your variadic template patch.
Btw., although it's not easter yet, I found a couple of more
variadic easter eggs. They should appear on bugzilla soon. ;-)
--
Summary: [4.3 regression] ICE with invalid parameter pack
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31431
[Bug c++/31431] [4.3 regression] ICE with invalid parameter pack
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31431
[Bug c++/31432] New: [4.3 regression] ICE with invalid parameter pack for template struct
More fallout from the variadic templates on mainline:
===
templatetypename..., typename struct A
{
enum { N };
};
Aint,int a;
===
bug.cc:1: error: parameter pack 'template-parameter-1-1' must be at the end
of the template parameter list
bug.cc: In instantiation of 'Aint, int':
bug.cc:6: instantiated from here
bug.cc:2: error: template argument 1 is invalid
bug.cc:2: error: template argument 1 is invalid
bug.cc:3: error: template argument 1 is invalid
bug.cc:3: error: template argument 1 is invalid
bug.cc:3: internal compiler error: tree check: expected class 'type', have
'exceptional' (error_mark) in tsubst_decl, at cp/pt.c:7889
Please submit a full bug report, [etc.]
Btw, why do we have to emit error: template argument 1 is invalid
four times?
--
Summary: [4.3 regression] ICE with invalid parameter pack for
template struct
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, error-recovery, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31432
[Bug fortran/31257] ICE in gfc_conv_expr_descriptor
--- Comment #1 from dfranke at gcc dot gnu dot org 2007-04-02 20:27 --- Adding this to TRANSFER meta-bug, as frame 3 in the backtrace indicates a relation. No confirmation as I can not tell whether it is a dupe or not. (gdb) bt #0 fancy_abort (file=0x86e4fec ../../../gcc/gcc/fortran/trans-array.c, line=4472, function=0x86e54c7 gfc_conv_expr_descriptor) at ../../../gcc/gcc/diagnostic.c:656 #1 0x080baf5c in gfc_conv_expr_descriptor (se=0xbfa27ad4, expr=0x8894850, ss=0x8895b80) at ../../../gcc/gcc/fortran/trans-array.c:4472 #2 0x080bc19f in gfc_conv_array_parameter (se=0xbfa27ad4, expr=0x8894850, ss=0x8895b80, g77=1) at ../../../gcc/gcc/fortran/trans-array.c:4786 #3 0x080d68fa in gfc_conv_intrinsic_transfer (se=0xbfa281ec, expr=0x8894770) at ../../../gcc/gcc/fortran/trans-intrinsic.c:3111 #4 0x080cc3c2 in gfc_conv_function_expr (se=0xbfa281ec, expr=0x8894850) at ../../../gcc/gcc/fortran/trans-expr.c:2689 #5 0x080cc8e9 in gfc_conv_expr (se=0xbfa281ec, expr=0x8894770) at ../../../gcc/gcc/fortran/trans-expr.c:3129 #6 0x080ce928 in gfc_trans_assignment (expr1=0x8894270, expr2=0x8894770, init_flag=0 '\0') at ../../../gcc/gcc/fortran/trans-expr.c:3823 #7 0x080cf131 in gfc_trans_assign (code=0x8895af8) at ../../../gcc/gcc/fortran/trans-expr.c:3985 #8 0x080b07dd in gfc_trans_code (code=0x8895af8) at ../../../gcc/gcc/fortran/trans.c:473 #9 0x080c7d06 in gfc_generate_function_code (ns=0x885a1e8) at ../../../gcc/gcc/fortran/trans-decl.c:3217 #10 0x0808c2b4 in gfc_parse_file () at ../../../gcc/gcc/fortran/parse.c:3261 #11 0x080ab660 in gfc_be_parse_file (set_yydebug=0) at ../../../gcc/gcc/fortran/f95-lang.c:305 #12 0x0830042d in toplev_main (argc=4, argv=0xbfa284c4) at ../../../gcc/gcc/toplev.c:1050 #13 0x080ed162 in main (argc=2, argv=0x6) at ../../../gcc/gcc/main.c:35 -- dfranke at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO||31237 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31257
[Bug c++/31432] [4.3 regression] ICE with invalid parameter pack for template struct
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31432
[Bug c++/31433] New: [4.3 regression] ICE with invalid parameter pack for template struct
More fallout from the variadic templates on mainline:
===
templatetypename..., typename struct A
{
static int i;
};
Aint, int a;
Achar,int b;
===
bug.cc:1: error: parameter pack 'template-parameter-1-1' must be at the end
of the template parameter list
bug.cc: In instantiation of 'Aint, int':
bug.cc:6: instantiated from here
bug.cc:2: error: template argument 1 is invalid
bug.cc:2: error: template argument 1 is invalid
bug.cc:3: error: template argument 1 is invalid
bug.cc: In instantiation of 'Achar, int':
bug.cc:7: instantiated from here
bug.cc:2: error: template argument 1 is invalid
bug.cc:2: error: template argument 1 is invalid
bug.cc:3: error: template argument 1 is invalid
bug.cc:3: internal compiler error: in finish_member_declaration, at
cp/semantics.c:2270
Please submit a full bug report, [etc.]
This is very similar to PR31432, but needs two instantiations of
the template to trigger an ICE.
--
Summary: [4.3 regression] ICE with invalid parameter pack for
template struct
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, error-recovery, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31433
[Bug c++/31433] [4.3 regression] ICE with invalid parameter pack for template struct
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31433
[Bug c++/31434] New: [4.3 regression] ICE with invalid use of parameter pack in function arg
More fallout from the variadic templates on mainline:
===
templatetypename... T void foo(const T...) {}
void bar()
{
foo(0);
}
===
bug.cc: In function 'void foo(T ...) [with T = int]':
bug.cc:5: instantiated from here
bug.cc:1: internal compiler error: tree check: expected tree_vec, have
error_mark in regenerate_decl_from_template, at cp/pt.c:13791
Please submit a full bug report, [etc.]
The code is (IMHO wrongfully) accepted if I replace the definition of foo by a
declaration.
--
Summary: [4.3 regression] ICE with invalid use of parameter pack
in function arg
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, accepts-invalid, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31434
