Re: M32C vs PR tree-optimization/39233
On Wed, 15 Apr 2009, DJ Delorie wrote: yes; however, maybe it would be easier to wait till Richard finishes the work on not representing the overflow semantics in types (assuming that's going to happen say in a few weeks?), which should make the fix unnecessary, Another thought - is this bug in the 4.4 branch? If so, a 4.4 fix may be needed too. Note that the issue is with our representation of POINTER_PLUS_EXPR which insists on using sizetype for the pointer offset argument (where I don't remember if m32c uses a bigger or smaller mode for sizetype than for pointers). Whenever the sizes of the modes for pointers and sizetype do not match we have a problem. Note that while this particular issue may likely be fixed with the no-undefined-overflow branch work the above much general issue is _not_ fixed by it. Richard.
Re: M32C vs PR tree-optimization/39233
Note that the issue is with our representation of POINTER_PLUS_EXPR which insists on using sizetype for the pointer offset argument (where I don't remember if m32c uses a bigger or smaller mode for sizetype than for pointers). Whenever the sizes of the modes for pointers and sizetype do not match we have a problem. Note that while this particular issue may likely be fixed with the no-undefined-overflow branch work the above much general issue is _not_ fixed by it. What about forbidding pointer induction variables completely if the modes for sizetype and pointers do not match? Paolo
Re: M32C vs PR tree-optimization/39233
On Wed, 15 Apr 2009, DJ Delorie wrote: As of this fix (yes, I know it was some time ago - I've been busy), the m32c-elf build fails building the target libiberty: ./cc1 -fpreprocessed regex.i -quiet -dumpbase regex.c -mcpu=m32cm \ -auxbase-strip regex.o -g -O2 -W -Wall -Wwrite-strings -Wc++-compat \ -Wstrict-prototypes -pedantic -version -o regex.s In file included from ../../../../gcc/libiberty/regex.c:639: ../../../../gcc/libiberty/regex.c: In function 'byte_re_match_2_internal': ../../../../gcc/libiberty/regex.c:7481: internal compiler error: in gen_add2_insn, at optabs.c:4733 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. cc1.r144405.20090224-060515 - failed The problem is, you *can't* treat pointers and integers the same on m32c, as there is no integral type (16-bit? 32?) the same size as a pointer (24 bits). Pointer math and pointer compatisons need to be done with pointer types. [ gdb ] where #0 fancy_abort (file=0x87e22a8 ../../gcc/gcc/optabs.c, line=4746, function=0x87e28c9 gen_add2_insn) at ../../gcc/gcc/diagnostic.c:724 #1 0x0837ddc5 in gen_add2_insn (x=0xb7993bb0, y=0xb7993b80) at ../../gcc/gcc/optabs.c:4745 #2 0x083f9df7 in gen_reload (out=0xb7993bb0, in=0xb7d086a8, opnum=0, type=RELOAD_FOR_INPUT) at ../../gcc/gcc/reload1.c:8248 #3 0x083fa959 in emit_input_reload_insns () at ../../gcc/gcc/reload1.c:7217 #4 do_input_reload (chain=value optimized out, rl=0x8896fcc, j=1) at ../../gcc/gcc/reload1.c:7511 #5 0x083ff278 in emit_reload_insns () at ../../gcc/gcc/reload1.c:7702 #6 reload_as_needed (live_known=1) at ../../gcc/gcc/reload1.c:4217 #7 0x084040f9 in reload (first=0xb7c8cd80, global=1) at ../../gcc/gcc/reload1.c:1169 #8 0x0832f799 in ira (f=value optimized out) at ../../gcc/gcc/ira.c:3239 #9 0x08331b50 in rest_of_handle_ira () at ../../gcc/gcc/ira.c:3309 #10 0x08396aed in execute_one_pass (pass=0x884a200) at ../../gcc/gcc/passes.c:1290 #11 0x08396d5c in execute_pass_list (pass=0x884a200) at ../../gcc/gcc/passes.c:1339 #12 0x08396d6f in execute_pass_list (pass=0x886bce0) at ../../gcc/gcc/passes.c:1340 #13 0x084aca80 in tree_rest_of_compilation (fndecl=0xb7fb5400) at ../../gcc/gcc/tree-optimize.c:437 #14 0x0860d3e2 in cgraph_expand_function (node=0xb7e84680) at ../../gcc/gcc/cgraphunit.c:1048 #15 0x0860f23f in cgraph_expand_all_functions () at ../../gcc/gcc/cgraphunit.c:1107 #16 cgraph_optimize () at ../../gcc/gcc/cgraphunit.c:1312 #17 0x080a5c0b in c_write_global_declarations () at ../../gcc/gcc/c-decl.c:8174 #18 0x0845817b in compile_file () at ../../gcc/gcc/toplev.c:989 #19 do_compile () at ../../gcc/gcc/toplev.c:2243 #20 toplev_main (argc=20, argv=0xb974) at ../../gcc/gcc/toplev.c:2278 #21 0x081266e2 in main (argc=Cannot access memory at address 0x23 ) at ../../gcc/gcc/main.c:35 [ gdb ] call debug_reload(rl) Reload 0: reload_in (HI) = (reg:HI 377 [ D.9641 ]) A_REGS, RELOAD_FOR_INPUT_ADDRESS (opnum = 0) reload_in_reg: (reg:HI 377 [ D.9641 ]) reload_reg_rtx: (reg:HI 4 a0) Reload 1: reload_in (PSI) = (plus:PSI (reg:HI 377 [ D.9641 ]) (const_int 4 [0x4])) A_REGS, RELOAD_FOR_INPUT (opnum = 0), inc by 4 reload_in_reg: (plus:PSI (reg:HI 377 [ D.9641 ]) (const_int 4 [0x4])) reload_reg_rtx: (reg:PSI 4 a0) Reload 2: reload_in (PSI) = (mem/f:PSI (reg/f:PSI 5 a1 [995]) [7 S4 A8]) A_HI_MEM_REGS, RELOAD_FOR_INPUT (opnum = 1), optional reload_in_reg: (mem/f:PSI (reg/f:PSI 5 a1 [995]) [7 S4 A8]) Note (plus:PSI (reg:HI) (const_int)) - the mode conflict between PSI and HI causes problems. Can we somehow make this fix contingent on ports that have suitable integral modes? I'm not sure if this is the same problem, but didn't I suggest in the past to fix this up during expansion? That is, if we end up with a POINTER_PLUS_EXPR with different mode size pointer and offset promote (or demote) the offset argument to pointer size properly? What happened to these patch snippets I sent you? Would they fix this issue? Thanks, Richard.
Snapshots of PPL 0.10.2 available for testing
All the problems of PPL 0.10.1 we are aware of have been fixed in the snapshot of PPL 0.10.2 available at ftp://ftp.cs.unipr.it/pub/ppl/snapshots/ In particular here is what has changed: - Correctly detect GMP 4.3.0. - Fixed the C interface library version information. - Test program tests/Polyhedron/memory1 disabled on the zSeries s390x platform. - Makefiles fixed so as to avoid failure of `make -n check'. If no further issues are reported, that snapshot will be relabeled PPL 0.10.2 and released on Saturday, April 18, 2009. Thanks to all who provided feedback. All the best, Roberto -- Prof. Roberto Bagnara Computer Science Group Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:bagn...@cs.unipr.it
Re: Snapshots of PPL 0.10.2 available for testing
On Thu, Apr 16, 2009 at 2:08 PM, Roberto Bagnara bagn...@cs.unipr.it wrote: All the problems of PPL 0.10.1 we are aware of have been fixed in the snapshot of PPL 0.10.2 available at ftp://ftp.cs.unipr.it/pub/ppl/snapshots/ In particular here is what has changed: - Correctly detect GMP 4.3.0. - Fixed the C interface library version information. - Test program tests/Polyhedron/memory1 disabled on the zSeries s390x platform. Huh. It looks like the test only randomly fails. Thus I didn't notice that the preprocessor define is __s390x__ instead of __s390x. Otherwise it works all fine now. Thanks, Richard.
Re: M32C vs PR tree-optimization/39233
I'm not sure if this is the same problem, but didn't I suggest in the past to fix this up during expansion? That is, if we end up with a POINTER_PLUS_EXPR with different mode size pointer and offset promote (or demote) the offset argument to pointer size properly? What happened to these patch snippets I sent you? Would they fix this issue? I don't remember every patch you sent, but Ive been careful to test everything you've offered and reported it's effects. If you can recall which patch it was, I'll test it again. I suspect that promoting a short to a pointer won't work right anyway, as it means that pointers will always have the upper 8 bits masked off. The root of the problem is using HImode integers to store PSImode pointers.
Diagnostic Messaging Suggestion
Suggested Messaging: Messaging seems redundant in indicating that function has
been redifined twice. One of the messages should be removed. More to the point,
I think the messaging may be erroneous - code fragment follows.
g++-4 Diagnostic Messaging
In file included from partition.cpp:66:
irange.h: In function 'std::ostream operator(std::ostream,
ciRange_2::sRange_2)':
irange.h:102: error: redefinition of 'std::ostream operator(std::ostream,
ciRange_2::sRange_2)'
irange.h:102: error: 'std::ostream operator(std::ostream,
ciRange_2::sRange_2)' previously defined here
Code Fragment
class ciRange_2 : public iRange_List { // low, high
public:
struct sRange_2 { double RLo;// Low range value
double RHi; }; // High range value
friend istream operator(istream stream, ciRange_2::sRange_2 Range);
friend ostream operator(ostream stream, ciRange_2::sRange_2 Range);
}; // class ciRange_2
istream operator(istream stream, ciRange_2::sRange_2 Range);
ostream operator(ostream stream, ciRange_2::sRange_2 Range) {
stream setw(9) Range.RLo setw(9) Range.RHi;
}
Re: Diagnostic Messaging Suggestion
On Thu, Apr 16, 2009 at 12:06 PM, Arthur Schwarz
aschwarz1...@verizon.net wrote:
Suggested Messaging: Messaging seems redundant in indicating that function
has been redifined twice. One of the messages should be removed. More to the
point, I think the messaging may be erroneous - code fragment follows.
g++-4 Diagnostic Messaging
In file included from partition.cpp:66:
irange.h: In function 'std::ostream operator(std::ostream,
ciRange_2::sRange_2)':
irange.h:102: error: redefinition of 'std::ostream operator(std::ostream,
ciRange_2::sRange_2)'
irange.h:102: error: 'std::ostream operator(std::ostream,
ciRange_2::sRange_2)' previously defined here
Code Fragment
class ciRange_2 : public iRange_List { // low, high
public:
struct sRange_2 { double RLo; // Low range value
double RHi; }; // High range value
friend istream operator(istream stream, ciRange_2::sRange_2 Range);
friend ostream operator(ostream stream, ciRange_2::sRange_2 Range);
}; // class ciRange_2
istream operator(istream stream, ciRange_2::sRange_2 Range);
ostream operator(ostream stream, ciRange_2::sRange_2 Range) {
stream setw(9) Range.RLo setw(9) Range.RHi;
}
Can you show code that reproduces the issue? My best guess is that a
header file is included twice, and lacks guards, hence the message is
correct: the function is being defined twice, from the same source
location.
-- James
Re: Diagnostic Messaging Suggestion
Can you show code that reproduces the issue? My best
guess is that a
header file is included twice, and lacks guards, hence the
message is
correct: the function is being defined twice, from the same
source
location.
-- James
Code (unadulterated and full of original lacerations) -
/*
* File: irange.h
* Author: Arthur Schwarz
*
* Created on April 13, 2009, 1:23 PM
*/
#ifndef _IRANGE_H
#define _IRANGE_H
# include ios
# include iomanip
# include istream
# include ostream
# include fstream
# include sstream
# include common.h
class iRange_List : public cDebug{ // input ranges
private:
// Processing of range buffer: Ndx, Size, BufferSize, Ranges, TempStream
// Ranges[Ndx] : Ndx0..BufferSize-1
// if (Ndx == BufferSize) TempStream.write(Ranges[Ndx]; Size +=
BufferSize; Ndx = 0;
fstream TempStream; // Temporary Stream
static
long const BufferSize; // Input buffer size
longNdx; // Index in Ranges buffer
longSize;// Total number ranges used
cRange ErrorRange;
protected:
cRange* Ranges; // All input ranges
longErrorCount; // Number of errors found
protected:
//double Atod(string Range, long id);
virtual
void DData () { string str(80, ' ');
ostringstream stream(str);
stream iRange_List
setw(9) Ndx ,
setw(9) Size ,
setw(9) ErrorCountendl;
cDebug::DData(str);
};
long Next() { if ( ++Ndx BufferSize) return Ndx;
TempStream.write((char*)Ranges, sizeof(Ranges));
Size += BufferSize;
return (Ndx = 0);
};
void Flush();
public:
iRange_List();
iRange_List(const iRange_List orig);
virtual ~iRange_List();
long GetSize() { return Size; }
void PrintRange() { for(long i = 0; i Ndx; i++) Stdout setw(9) i
:
Ranges[i]
endl;
}; // PrintRange()
virtual
bool Read() = 0;
cRange operator[](long Ndx) { return ((Ndx =0 ) (Ndx Size))?
Ranges[Ndx]: ErrorRange; }
}; // class iRange_List
class ciRange_2 : public iRange_List { // low, high
public:
struct sRange_2 { double RLo;// Low range value
double RHi; }; // High range value
ciRange_2() : iRange_List() { }
virtual
bool Read();
friend istream operator(istream stream, ciRange_2::sRange_2 Range);
friend ostream operator(ostream stream, ciRange_2::sRange_2 Range);
}; // class ciRange_2
class ciRange_3 : public iRange_List { // low, high, id
public:
struct sRange_3 { double RLo; // Low range value
double RHi; // High range value
longDatum; }; // User supplied datum
ciRange_3() : iRange_List() { }
virtual
bool Read();
friend istream operator(istream stream, sRange_3 Range);
friend ostream operator(ostream stream, ciRange_3::sRange_3 Range);
}; // class ciRange_3
#endif /* _IRANGE_H */
//
//Debug Streams
//
istream operator(istream stream, ciRange_2::sRange_2 Range);
istream operator(istream stream, ciRange_3::sRange_3 Range);
ostream operator(ostream stream, ciRange_2::sRange_2 Range) {
stream setw(9) Range.RLo setw(9) Range.RHi;
}
ostream operator(ostream stream, ciRange_3::sRange_3 Range) {
stream setw(9) Range.RLo setw(9) Range.RHi
setw(9) Range.Datum;
}
Re: Diagnostic Messaging Suggestion
I forgot to say 'thanks James', thanks. Well, spurred on by the whimsy that I need a solution to the problem (however dolorous), I experimented. I've commented most everything at least once and the net effect is that only the 'operator' gets a nasty message. I've checked the include files that I've written and they all seem clean of heresies. The 'operator' files are unaffected, and with them gone, I still get an error on the 'operator' function. The only thing that I can think of, and I think it remote, is that the functions refer to a public structure internal to a class. The 'operator' functions refer to their respective classes. Again, I've removed all of my friends but one 'operator' and this gets the error. Now I think I know C++ (although, to be honest, I have strong, personal, doubts) and I can't think what I missed. However, the initial statement still holds, the second diagnostic messages adds no clarity and seems redundant. Further, if there was a cause of conflict with a redefinition, it would be useful to include the original conflicting declaration. Perhaps something like: line no: error: redefinition of function at line no illegal. note: istream operator (bool val ); istream operator (short val ); o o o the note: stuff is from cplusplus.com @ http://cplusplus.com/reference/iostream/istream/operator%3E%3E/ So, a concrete suggestion at to messaging and an individual first, a puzzler. I really need help on the puzzler. thanks art
Re: Diagnostic Messaging Suggestion
Thanks to everyone. The rock has dropped. The answer is quoted below: My best guess is that a header file is included twice, and lacks guards, hence the message is correct: the function is being defined twice, from the same source location. I had put my friends following my 'include guard'. As we all know, when your guard is down you can get sucker-punched. Although you should never try to teach an old dog new tricks, with luck and a good tail wind this will never happen again. thanks art PS: You are now all my best friend. Sorry.
gcc-4.5-20090416 is now available
Snapshot gcc-4.5-20090416 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20090416/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.5 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 146216 You'll find: gcc-4.5-20090416.tar.bz2 Complete GCC (includes all of below) gcc-core-4.5-20090416.tar.bz2 C front end and core compiler gcc-ada-4.5-20090416.tar.bz2 Ada front end and runtime gcc-fortran-4.5-20090416.tar.bz2 Fortran front end and runtime gcc-g++-4.5-20090416.tar.bz2 C++ front end and runtime gcc-java-4.5-20090416.tar.bz2 Java front end and runtime gcc-objc-4.5-20090416.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.5-20090416.tar.bz2The GCC testsuite Diffs from 4.5-20090409 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.5 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: Diagnostic Messaging Suggestion
On Thu, Apr 16, 2009 at 03:40:47PM -0700, Arthur Schwarz wrote: The rock has dropped. The answer is quoted below: My best guess is that a header file is included twice, and lacks guards, hence the message is correct: the function is being defined twice, from the same source location. Yes, I've had to diagnose this one before; it doesn't happen with my own code because I use include guards, but I've had to help others. It would be cool if there were a way of distinguishing the case where the same header is being processed twice. We might see foo.h:11 error: redefinition of `a' foo.h:11 error: `a' previously defined here but the first foo.h:11 might represent the 2300'th line read by the compiler, while the second foo.h:11 might represent the 2194'th line. If, for definitions, the compiler keeps track of this detail, it would be possible to reliably print foo.h:11 error: redefinition of `a' (file was included more than once) if the printable line number is the same but the internal line number is different.
Advantage of switch-case
Hi All, Is there any advantage of using switch-case over if-else. I mean any internal optimizations, gcc can do on a Linux i386 machine?. Is it saving any machine instructions for us ?. Regards, Shameem _ So many new options, so little time. Windows Live Messenger. http://www.microsoft.com/india/windows/windowslive/messenger.aspx
Re: The gcc-in-cxx branch now completes bootstrap
Ian Lance Taylor wrote: My plan going forward is as follows (when we are back in stage 1): FWIW, I think this is a great plan. Thanks, -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: Advantage of switch-case
On Thu, Apr 16, 2009 at 09:07:58PM -0700, Shameem Ahamed wrote: Is there any advantage of using switch-case over if-else. I mean any internal optimizations, gcc can do on a Linux i386 machine?. The optimizations in question are architecture-independent, though there would undoubtedly be processor-specific weights. Given a switch statement, gcc will generate either a balanced binary tree or a jump table, depending on the number of branches and their density. It has some freedom to optimize this structure that it might not have for an if-then-else structure. But I think that the difference is only going to be significant for a large switch (with many branches); if there are few branches, the jump table won't be a win (so won't be chosen), and the balanced tree would be about the same as what you would write. I would say that if a switch statement is a natural way to code something, it would be wise to prefer it to if-then-else if there are four or more branches (I admit I have no hard justification for the four here); for fewer I'd make the decision based on clarity and maintainability. Switch statements also give compilers more freedom to rearrange based on profile-directed optimization. There was a GCC Summit paper on improving GCC's code generation for switch statements, see http://ols.fedoraproject.org/GCC/Reprints-2006/wienskoski-reprint.pdf I don't know how much of that work got into the compiler, probably it isn't in the 4.2.x version we're using now.
Re: Advantage of switch-case
On Thu, Apr 16, 2009 at 10:12:10PM -0700, Joe Buck wrote: I don't know how much of that work got into the compiler, probably it isn't in the 4.2.x version we're using now. I should clarify that remark. In production work right now I'm not using the current gcc, and am not using profile-directed optimization, so I can't say how well it works with respect to switch statements.
[Bug bootstrap/36481] gcc fails to build on Solaris x86 - it forgets the locations of libmpfr
--- Comment #9 from sebastian dot wenzler at hp dot com 2009-04-16 06:40
---
I had the same problem with Solaris 10 on sparcv9 with gcc-4.3.3.
Environment:
1) binutils/2.15 2) bison/1.875 3) automake/1.4-p5 4) gcc/4.2.4
LD_RUN_PATH=/local/scratch/xhpsewe/424-64bit/lib/sparcv9:/local/scratch/xhpsewe/424-64bit/lib
PATH=/app/automake/1.4-p5/bin:/app/bison/1.875/bin:/app/binutils/2.15/bin:/local/scratch/xhpsewe/424-64bit/bin
~/gcc-4.3.3/configure --prefix /local/scratch/xhpsewe/gcc433-64bit
--enable-languages=c,c++ --with-gmp=/app/gmp/4.2.4 --with-mpfr=/app/mpfr/2.4.0
sparcv9-sun-solaris2.10
After applying the patch (2009-03-23 18:42) I get
make: Fatal error in reader: Makefile, line 51: Unexpected end of line seen
Current working directory
/local/scratch/builddir/build-sparcv9-sun-solaris2.10/fixincludes
*** Error code 1
The following command caused the error:
r=`${PWDCMD-pwd}`; export r; \
s=`cd /home/xhpsewe/gcc-4.3.3; ${PWDCMD-pwd}`; export s; \
FLEX=/home/xhpsewe/gcc-4.3.3/missing flex; export FLEX; LEX=lex; export
LEX; BISON=bison; export BISON; YACC=bison -y; export YACC; M4=m4;
export M4; MAKEINFO=/home/xhpsewe/gcc-4.3.3/missing makeinfo
--split-size=500 --split-size=500; export MAKEINFO; AR=ar; export
AR; AS=as; export AS; CC=sparcv9-sun-solaris2.10-gcc; export CC;
CFLAGS=-g -O2; export CFLAGS; CONFIG_SHELL=/bin/bash; export CONFIG_SHELL;
CXX=sparcv9-sun-solaris2.10-g++; export CXX; CXXFLAGS=-g -O2; export
CXXFLAGS; GCJ=; export GCJ; GFORTRAN=; export GFORTRAN;
DLLTOOL=dlltool; export DLLTOOL; LD=/usr/ccs/bin/ld; export LD;
LDFLAGS=; export LDFLAGS; NM=nm; export NM; RANLIB=ranlib; export
RANLIB; WINDRES=windres; export WINDRES; WINDMC=windmc; export WINDMC; \
(cd build-sparcv9-sun-solaris2.10/fixincludes \
make all)
make: Fatal error: Command failed for target `all-build-fixincludes'
Current working directory /local/scratch/builddir
*** Error code 1
The following command caused the error:
r=`${PWDCMD-pwd}`; export r; \
s=`cd /home/xhpsewe/gcc-4.3.3; ${PWDCMD-pwd}`; export s; \
if test -f stage1-lean ; then \
echo Skipping rebuild of stage1 ; \
else \
make stage1-start; \
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36481
[Bug fortran/39782] New: IO depends on uninitialised value
The following program CHARACTER(LEN=80) DATA DATA= OPEN(121245,FILE=/proc/self/statm,ACTION=READ,STATUS=OLD,ACCESS=STREAM) DO I=1,80 READ(121245,END=999) DATA(I:I) ENDDO 999 CLOSE(121245) DATA(I:80)= END under valgrind leads to : ==29139== Conditional jump or move depends on uninitialised value(s) ==29139==at 0x4BE48A5: finalize_transfer (transfer.c:2953) ==29139==by 0x4BE49E8: _gfortran_st_read_done (transfer.c:3092) ==29139==by 0x400A2B: MAIN__ (test.f90:5) ==29139==by 0x400B19: main (fmain.c:21) which I'm guessing would be a wrong code issue in the io lib. gcc version 4.4.0 20090414 (prerelease) [gcc-4_4-branch revision 146034] (GCC) -- Summary: IO depends on uninitialised value Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jv244 at cam dot ac dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39782
[Bug fortran/39782] IO depends on uninitialised value
--- Comment #1 from jv244 at cam dot ac dot uk 2009-04-16 07:31 --- no valgrind errors with g95 or NAG. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39782
[Bug middle-end/39625] [4.5 regression] Revision 145338 breaks ability to build Ada
--- Comment #28 from ebotcazou at gcc dot gnu dot org 2009-04-16 07:33 --- Created an attachment (id=17646) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17646action=view) Reduced testcase. To be gnatchop-ed and compiled at -O. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39625
[Bug middle-end/39625] [4.5 regression] Revision 145338 breaks ability to build Ada
--- Comment #29 from ebotcazou at gcc dot gnu dot org 2009-04-16 07:57 --- Richard, the removal of /* If the RHS of the MODIFY_EXPR may throw or make a nonlocal goto and the LHS is a user variable, then we need to introduce a formal temporary. This way the optimizers can determine that the user variable is only modified if evaluation of the RHS does not throw. */ from is_gimple_reg_or_call_rhs breaks __builtin_setjmp / __builtin_longjmp (and probably nonlocal gotos). -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39625
[Bug target/39717] [cond-optab] CSE does not put subregs into COMPAREs on many CC0 machines
--- Comment #2 from bonzini at gnu dot org 2009-04-16 08:04 --- Subject: Re: [cond-optab] CSE does not put subregs into COMPAREs on many CC0 machines Is this a cond-optab regression or just an observation? Yes, it causes extra moves on code using unions. Where we have r20:SI=r19:SF#0where X#0 = (subreg X 0) cc0=r20:SI is now r20:SI=r19:SF#0 cc0=cmp(r20:SI,0) and CSE is somehow not able to turn it into cc0=cmp(r19:SF#0,0) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39717
[Bug middle-end/39625] [4.5 regression] Revision 145338 breaks ability to build Ada
--- Comment #30 from rguenther at suse dot de 2009-04-16 08:06 --- Subject: Re: [4.5 regression] Revision 145338 breaks ability to build Ada On Thu, 16 Apr 2009, ebotcazou at gcc dot gnu dot org wrote: --- Comment #29 from ebotcazou at gcc dot gnu dot org 2009-04-16 07:57 --- Richard, the removal of /* If the RHS of the MODIFY_EXPR may throw or make a nonlocal goto and the LHS is a user variable, then we need to introduce a formal temporary. This way the optimizers can determine that the user variable is only modified if evaluation of the RHS does not throw. */ from is_gimple_reg_or_call_rhs breaks __builtin_setjmp / __builtin_longjmp (and probably nonlocal gotos). Do you happen to have a testcase? I compensated for the loss of the above during EH lowering when we split blocks at these points. Note the comment continued as - Don't force a temp of a non-renamable type; the copy could be - arbitrarily expensive. Instead we will generate a VDEF for - the assignment. */ and the check itself applied as - ((TREE_CODE (t) == CALL_EXPR TREE_SIDE_EFFECTS (t)) - || tree_could_throw_p (t))) thus all non-pure/const calls would get the extra copy. The intent of the patch was to make the gimple predicates valid after gimplification (and not only during it), so the fix should be applied during CFG creation or lowering. Thanks, Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39625
[Bug target/39779] ICE shifting byte to the right with constant 7FFFFFFF
--- Comment #1 from ubizjak at gmail dot com 2009-04-16 08:28 --- Confirmed also on i686-pc-linux-gnu. -- ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC target triplet||i686-pc-linux-gnu Known to fail||4.4.0 4.5.0 Last reconfirmed|-00-00 00:00:00 |2009-04-16 08:28:47 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39779
[Bug middle-end/39625] [4.5 regression] Revision 145338 breaks ability to build Ada
--- Comment #31 from ebotcazou at gcc dot gnu dot org 2009-04-16 08:33 --- Do you happen to have a testcase? Attached in the PR. bb 22: formal_24(ab) = p__proc_next (formal_6(ab)); goto bb 3; # formal_7(ab) = PHI formal_9(ab)(2), formal_5(ab)(3), formal_5(ab)(4), formal_7(ab)(6), formal_6(ab)(9), formal_6(ab)(10), formal_6(ab)(11), formal_6(ab)(12), formal_6(ab)(13), formal_24(ab)(22), formal_6(ab)(14), formal_6(ab)(15), formal_6(ab)(16), formal_6(ab)(17), formal_6(ab)(18), formal_6(ab)(19), formal_6(ab)(20) the reaching SSA_NAME on the abnormal edge is wrong. This breaks inlining. I compensated for the loss of the aboveduring EH lowering when we split blocks at these points. __builtin_setjmp / __builtin_longjmp and nonlocal gotos don't use the EH machinery, you need a specific treatment for them. The intent of the patch was to make the gimple predicates valid after gimplification (and not only during it), so the fix should be applied during CFG creation or lowering. OK. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39625
[Bug target/39780] internal compiler error: Segmentation fault
--- Comment #2 from ubizjak at gmail dot com 2009-04-16 08:35 --- It doesn't fail for me on linux-mingw cross. Can you please provide the backtrace? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39780
[Bug middle-end/39625] [4.5 regression] Revision 145338 breaks ability to build Ada
--- Comment #32 from rguenther at suse dot de 2009-04-16 08:45 --- Subject: Re: [4.5 regression] Revision 145338 breaks ability to build Ada On Thu, 16 Apr 2009, ebotcazou at gcc dot gnu dot org wrote: --- Comment #31 from ebotcazou at gcc dot gnu dot org 2009-04-16 08:33 --- Do you happen to have a testcase? Attached in the PR. bb 22: formal_24(ab) = p__proc_next (formal_6(ab)); goto bb 3; # formal_7(ab) = PHI formal_9(ab)(2), formal_5(ab)(3), formal_5(ab)(4), formal_7(ab)(6), formal_6(ab)(9), formal_6(ab)(10), formal_6(ab)(11), formal_6(ab)(12), formal_6(ab)(13), formal_24(ab)(22), formal_6(ab)(14), formal_6(ab)(15), formal_6(ab)(16), formal_6(ab)(17), formal_6(ab)(18), formal_6(ab)(19), formal_6(ab)(20) the reaching SSA_NAME on the abnormal edge is wrong. This breaks inlining. Hum, an Ada testcase ... so p__proc_next calls longjmp, correct? And the target in question uses SJLJ exceptions (so this particular case is an exception problem)? I wonder if a C testcase explicitly using setjmp/longjmp would be valid with all the constraints placed on how they interact on register variable values. I'll dig into where we deal with SJLJ EH lowering ... :/ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39625
[Bug c/39783] New: -ftls-model can not be specified independently of -fpic/-fpie
It is not possible to use -ftls-model to set the tls-model to global-dynamic for code compiled without -fpic. Code compiled without -fpic uses initial-exec or local-exec. This makes it impossible to link code that uses tls and is compiled without -fpic in shared libraries. -- Summary: -ftls-model can not be specified independently of - fpic/-fpie Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tom dot aernoudt at coware dot com 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=39783
[Bug middle-end/39625] [4.5 regression] Revision 145338 breaks ability to build Ada
--- Comment #35 from ebotcazou at gcc dot gnu dot org 2009-04-16 09:13 --- Ok, so we _do_ run lower_eh_constructs, but formal = p__proc_next (formal); returns false for stmt_could_throw_p (stmt). Why? (Not that I can follow the Ada testcase ... but I suppose the above function call returns abnormally) There are no exceptions. Is this Ada playing games behind the middle-end and implementing exceptions on its own pretending that there are none? In which case the LHS of the above stmt should be marked volatile at least - after all non-EH SJLJ stuff would need to follow C / POSIX requirements, no? Ada isn't playing anything, it's just using the existing generic support for __builtin_setjmp / __builtin_longjmp and nonlocal gotos which is distinct from the exception machinery. Compensating bits need to be added for it too. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39625
[Bug middle-end/39625] [4.5 Regression] Revision 145338 breaks ability to build Ada
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.5 regression] Revision |[4.5 Regression] Revision |145338 breaks ability to|145338 breaks ability to |build Ada |build Ada Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39625
[Bug middle-end/16660] attribute((aligned)) doesn't work for variables on the stack for greater than required alignement
--- Comment #17 from nospamname at web dot de 2009-04-16 09:22 --- I get same align problem on 68k amigaos Target.the rport and fix is old. its a middle end bug and i see the fix is not in the source i download (4.3.3) i can test this patch if you like, or have you something more new ? Here is mail i get last in gcc ML http://gcc.gnu.org/ml/gcc/2009-04/msg00395.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16660
[Bug middle-end/39625] [4.5 Regression] Revision 145338 breaks ability to build Ada
--- Comment #38 from rguenth at gcc dot gnu dot org 2009-04-16 10:45 --- Maybe fixed now (the reduced testcase is). Please re-open if not. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39625
[Bug middle-end/39625] [4.5 regression] Revision 145338 breaks ability to build Ada
--- Comment #34 from rguenth at gcc dot gnu dot org 2009-04-16 08:59 --- And of course the testcase compiles fine with -fexceptions. Hmmm? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39625
[Bug middle-end/39625] [4.5 regression] Revision 145338 breaks ability to build Ada
--- Comment #33 from rguenth at gcc dot gnu dot org 2009-04-16 08:58 --- Ok, so we _do_ run lower_eh_constructs, but formal = p__proc_next (formal); returns false for stmt_could_throw_p (stmt). Why? (Not that I can follow the Ada testcase ... but I suppose the above function call returns abnormally) Hm, I guess because flag_exceptions is false. Is this Ada playing games behind the middle-end and implementing exceptions on its own pretending that there are none? In which case the LHS of the above stmt should be marked volatile at least - after all non-EH SJLJ stuff would need to follow C / POSIX requirements, no? I'm of course sort of confused here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39625
[Bug middle-end/39625] [4.5 regression] Revision 145338 breaks ability to build Ada
--- Comment #36 from rguenth at gcc dot gnu dot org 2009-04-16 09:22 --- Created an attachment (id=17647) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17647action=view) patch Ok, I think I see the issue. The attached patch should fix it (it does fix the testcase). I am going to bootstrap/test it on x86_64-linux, can somebody check if this PR is fixed with the patch? -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39625
[Bug tree-optimization/39698] wrong types for vectorized reduction
--- Comment #2 from irar at il dot ibm dot com 2009-04-16 10:26 --- This patch fixes the type in pr34591.c (the vector type should be the type of the reduction variable because we are looking for its initial value, and not the type of the reduction statement, i.e., its RHS type): Index: tree-vect-loop.c === --- tree-vect-loop.c(revision 145457) +++ tree-vect-loop.c(working copy) @@ -2267,33 +2267,33 @@ get_initial_def_for_reduction (gimple st stmt_vec_info stmt_vinfo = vinfo_for_stmt (stmt); loop_vec_info loop_vinfo = STMT_VINFO_LOOP_VINFO (stmt_vinfo); struct loop *loop = LOOP_VINFO_LOOP (loop_vinfo); - tree vectype = STMT_VINFO_VECTYPE (stmt_vinfo); - int nunits = TYPE_VECTOR_SUBPARTS (vectype); - tree scalar_type = TREE_TYPE (vectype); + tree scalar_type = TREE_TYPE (init_val); + tree vectype = get_vectype_for_scalar_type (scalar_type); + int nunits; enum tree_code code = gimple_assign_rhs_code (stmt); - tree type = TREE_TYPE (init_val); - tree vecdef; tree def_for_init; tree init_def; tree t = NULL_TREE; int i; bool nested_in_vect_loop = false; - gcc_assert (POINTER_TYPE_P (type) || INTEGRAL_TYPE_P (type) || SCALAR_FLOAT_TYPE_P (type)); + gcc_assert (vectype); + nunits = TYPE_VECTOR_SUBPARTS (vectype); + + gcc_assert (POINTER_TYPE_P (scalar_type) || INTEGRAL_TYPE_P (scalar_type) + || SCALAR_FLOAT_TYPE_P (scalar_type)); if (nested_in_vect_loop_p (loop, stmt)) nested_in_vect_loop = true; else gcc_assert (loop == (gimple_bb (stmt))-loop_father); - vecdef = vect_get_vec_def_for_operand (init_val, stmt, NULL); - switch (code) case WIDEN_SUM_EXPR: case DOT_PROD_EXPR: case PLUS_EXPR: if (nested_in_vect_loop) - *adjustment_def = vecdef; + *adjustment_def = vect_get_vec_def_for_operand (init_val, stmt, NULL); else *adjustment_def = init_val; /* Create a vector of zeros for init_def. */ @@ -2310,7 +2310,7 @@ get_initial_def_for_reduction (gimple st case MIN_EXPR: case MAX_EXPR: *adjustment_def = NULL_TREE; -init_def = vecdef; +init_def = vect_get_vec_def_for_operand (init_val, stmt, NULL); break; default: (I also removed the creation of definition for the cases where it is not used). Tested on vectorizer testsuite. Ira -- irar at il dot ibm dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-04-16 10:26:32 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39698
[Bug fortran/39630] Fortran 2003: Procedure Pointer Components
--- Comment #2 from janus at gcc dot gnu dot org 2009-04-16 11:29 --- An example can be found in the following paper: Norman S. Clerman: Note on creating an array of procedure pointers ACM SIGPLAN Fortran Forum, Vol. 28, Issue 1 (2009) http://doi.acm.org/10.1145/1520752.1520753 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39630
[Bug rtl-optimization/39779] ICE shifting byte to the right with constant 7FFFFFFF
--- Comment #2 from ubizjak at gmail dot com 2009-04-16 11:37 --- It looks that convert_modes has some issues. When expanding shift RTX, convert_modes is called from #0 convert_modes (mode=QImode, oldmode=QImode, x=0xb7d05fe8, unsignedp=0) at ../../gcc-svn/trunk/gcc/expr.c:769 #1 0x083455ec in expand_binop_directly (mode=USQmode, binoptab=0x8a02148, op0=value optimized out, op1=0xb7d05fe8, target=0xb7d2a2d0, unsignedp=value optimized out, methods=OPTAB_DIRECT, last=0xb7c8f72c) at ../../gcc-svn/trunk/gcc/optabs.c:1488 #2 0x08343389 in expand_binop (mode=QImode, binoptab=0x8a02148, op0=0xb7d2a2e8, op1=0xb7d05fe8, target=0xb7d2a2d0, unsignedp=0, methods=OPTAB_DIRECT) at ../../gcc-svn/trunk/gcc/optabs.c:1601 #3 0x08209c95 in expand_shift (code=RSHIFT_EXPR, mode=QImode, shifted=0xb7d2a2e8, amount=0xb7d29ec4, target=0xb7d2a2d0, unsignedp=0) at ../../gcc-svn/trunk/gcc/expmed.c:2244 as: convert_modes (mode=QImode, oldmode=QImode, x=0xb7d05fe8, unsignedp=0) at ../../gcc-svn/trunk/gcc/expr.c:769 (gdb) p debug_rtx (x) (const_int -557921043 [0xdebecced]) We immediatelly hit: if (mode == oldmode) return x; so, we return (const_int -557921043 [0xdebecced]) that doesn't satisfy QImode constraint. The compilation goes downhill from there... This looks like generic RTL optimization problem. -- ubizjak at gmail dot com changed: What|Removed |Added Component|target |rtl-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39779
[Bug tree-optimization/39698] wrong types for vectorized reduction
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-04-16 12:07 --- I'm bootstrapping / testing the patch and will take care of committing. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2009-04-16 10:26:32 |2009-04-16 12:07:34 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39698
[Bug target/39780] internal compiler error: Segmentation fault
--- Comment #3 from kuchen_ at gmx dot de 2009-04-16 12:00 --- The backtrace from gcc? How do I get that? (It's not crashing, so it's hard to find the point from which the backtrace should be generated...) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39780
[Bug rtl-optimization/39779] ICE shifting byte to the right with constant 7FFFFFFF
--- Comment #3 from ubizjak at gmail dot com 2009-04-16 12:26 ---
This testcase fails for all optimization levels:
--cut here--
/* { dg-do compile } */
/* { dg-options -w } */
int test (char v1)
{
v1 = 0xdebecced;
return v1;
}
--cut here--
Follwing patch fixes the failure, but introduces several testsuite failures:
--cut here--
Index: optabs.c
===
--- optabs.c(revision 146146)
+++ optabs.c(working copy)
@@ -1478,18 +1478,10 @@ expand_binop_directly (enum machine_mode
for their mode. */
if (GET_MODE (xop0) != mode0 mode0 != VOIDmode)
-xop0 = convert_modes (mode0,
- GET_MODE (xop0) != VOIDmode
- ? GET_MODE (xop0)
- : mode,
- xop0, unsignedp);
+xop0 = convert_modes (mode0, GET_MODE (xop0), xop0, unsignedp);
if (GET_MODE (xop1) != mode1 mode1 != VOIDmode)
-xop1 = convert_modes (mode1,
- GET_MODE (xop1) != VOIDmode
- ? GET_MODE (xop1)
- : mode,
- xop1, unsignedp);
+xop1 = convert_modes (mode1, GET_MODE (xop1), xop1, unsignedp);
/* If operation is commutative,
try to make the first operand a register.
--cut here--
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39779
[Bug tree-optimization/39698] wrong types for vectorized reduction
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-04-16 12:45 --- Subject: Bug 39698 Author: rguenth Date: Thu Apr 16 12:44:46 2009 New Revision: 146180 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=146180 Log: 2009-04-16 Richard Guenther rguent...@suse.de Ira Rosen i...@il.ibm.com PR tree-optimization/39698 * tree-vect-loop.c (get_initial_def_for_reduction): Use the type of the reduction variable. Only generate the def if it is needed. * omp-low.c (expand_omp_for_generic): When converting to a pointer make sure to first convert to an integer of the same precision. * tree-vect-loop-manip.c (vect_update_ivs_after_vectorizer): Retain the type of the evolution correctly in computing the new induction variable base. Modified: trunk/gcc/ChangeLog trunk/gcc/omp-low.c trunk/gcc/tree-vect-loop-manip.c trunk/gcc/tree-vect-loop.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39698
[Bug tree-optimization/39698] wrong types for vectorized reduction
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-04-16 12:45 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39698
[Bug fortran/39782] [4.5/4.4/4.3 Regression] IO depends on uninitialised value
--- Comment #2 from jv244 at cam dot ac dot uk 2009-04-16 12:56 --- seemingly works fine with 4.2.3 -- jv244 at cam dot ac dot uk changed: What|Removed |Added Known to fail|4.4.0 |4.4.0 4.3.3 4.5.0 Known to work||4.2.3 Summary|IO depends on uninitialised |[4.5/4.4/4.3 Regression] IO |value |depends on uninitialised ||value http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39782
[Bug fortran/39782] [4.3/4.4/4.5 Regression] IO depends on uninitialised value
-- jv244 at cam dot ac dot uk changed: What|Removed |Added Summary|[4.5/4.4/4.3 Regression] IO |[4.3/4.4/4.5 Regression] IO |depends on uninitialised|depends on uninitialised |value |value Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39782
[Bug target/39780] internal compiler error: Segmentation fault
--- Comment #4 from ubizjak at gmail dot com 2009-04-16 13:09 --- (In reply to comment #3) The backtrace from gcc? How do I get that? (It's not crashing, so it's hard to find the point from which the backtrace should be generated...) gdb /some/dir/cc1 (gdb) break fancy_abort (gdb) set args -some -args virt.c (gdb) run crash (gdb) bt -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39780
[Bug target/39783] -ftls-model can not be specified independently of -fpic/-fpie
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-04-16 13:52 --- code in shared libraries have to be PIC code -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39783
[Bug target/39780] internal compiler error: Segmentation fault
--- Comment #5 from kuchen_ at gmx dot de 2009-04-16 14:01 --- Thanks for help! (gdb) run Starting program: C:\osdev\kos/..\tools\gcc-4.3.3\i586-elf\bin\cc1.exe -Iinclude -Iinclude/arch/i386 -Ikernel/include -O3 -g -ffreestanding -Wall -o virt.o ker nel/mm/virt.c [New thread 1332.0xd08] bscanfwdIn file included from kernel/include/debug.h:4, from kernel/mm/virt.c:4: kernel/include/config.h:8:2: warning: #warning Use kos/config.h instead of confi g.h pm_is_blocked_for getaddr getflags map_working_table init_paging vm_map_page vm _unmap_page vm_map_range vm_unmap_range vm_find_addr vm_find_range vm_alloc_addr vm_free_addr vm_identity_map vm_alloc_page vm_alloc_range vm_free_page vm_free_ range get_ptab_entry vm_resolve_virt vm_is_userspace Analyzing compilation unit Performing interprocedural optimizations visibility early_local_cleanups Program received signal SIGSEGV, Segmentation fault. 0x7105b436 in strsep () from C:\msys\1.0\bin\msys-1.0.dll (gdb) bt #0 0x7105b436 in strsep () from C:\msys\1.0\bin\msys-1.0.dll #1 0x7102d259 in msys-1!calloc () from C:\msys\1.0\bin\msys-1.0.dll #2 0x7108c104 in msys-1!_ctype_ () from C:\msys\1.0\bin\msys-1.0.dll #3 0x7109874c in msys-1!__ctype_ptr () from C:\msys\1.0\bin\msys-1.0.dll #4 0x in ?? () (gdb) -O1 and -O2 result in the exact same error, only without any optimization the file gets compiled. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39780
[Bug target/39783] -ftls-model can not be specified independently of -fpic/-fpie
--- Comment #2 from tom dot aernoudt at coware dot com 2009-04-16 14:07 --- Aren't shared libraries that are compiled without -fPIC supposed to work on x86? On other platforms this may not work, but I thought that on x86 this is not required. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39783
[Bug target/39783] -ftls-model can not be specified independently of -fpic/-fpie
--- Comment #3 from hjl dot tools at gmail dot com 2009-04-16 14:16 --- (In reply to comment #2) Aren't shared libraries that are compiled without -fPIC supposed to work on x86? It is not supposed to work. It is happens to work. Now it happens not to work for this combination. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39783
[Bug c++/39754] [4.5 Regression] ICE: tree check: accessed elt 2 of tree_vec with 1 elts in tsubst, at cp/pt.c:9248
--- Comment #5 from gcc at abeckmann dot de 2009-04-16 14:28 --- It does compile successfully using 4.4.0 built with --enable-checking. Is there anyting else to enable these tree checks? $ x86_64-linux-gnu-g++-4.4.x -v -c PR39754.min.ii echo SUCCESS Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../gcc-4_4-branch/configure --prefix=/opt/software/gcc-x86_64/gcc-4.4.x --program-suffix=-4.4.x --enable-languages=c,c++ --enable-checking Thread model: posix gcc version 4.4.0 20090413 (prerelease) (GCC) COLLECT_GCC_OPTIONS='-v' '-c' '-shared-libgcc' '-mtune=generic' /opt/software/gcc-x86_64/gcc-4.4.x/libexec/gcc/x86_64-unknown-linux-gnu/4.4.0/cc1plus -fpreprocessed PR39754.min.ii -quiet -dumpbase PR39754.min.ii -mtune=generic -auxbase PR39754.min -version -o /tmp/ccH60tOe.s GNU C++ (GCC) version 4.4.0 20090413 (prerelease) (x86_64-unknown-linux-gnu) compiled by GNU C version 4.4.0 20090413 (prerelease), GMP version 4.2.2, MPFR version 2.3.1. GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: 4c95a5cf24794a394976148039ecc611 COLLECT_GCC_OPTIONS='-v' '-c' '-shared-libgcc' '-mtune=generic' as -V -Qy -o PR39754.min.o /tmp/ccH60tOe.s GNU assembler version 2.19.1 (x86_64-linux-gnu) using BFD version (GNU Binutils for Debian) 2.19.1 COMPILER_PATH=/opt/software/gcc-x86_64/gcc-4.4.x/libexec/gcc/x86_64-unknown-linux-gnu/4.4.0/:/opt/software/gcc-x86_64/gcc-4.4.x/libexec/gcc/x86_64-unknown-linux-gnu/4.4.0/:/opt/software/gcc-x86_64/gcc-4.4.x/libexec/gcc/x86_64-unknown-linux-gnu/:/opt/software/gcc-x86_64/gcc-4.4.x/lib/gcc/x86_64-unknown-linux-gnu/4.4.0/:/opt/software/gcc-x86_64/gcc-4.4.x/lib/gcc/x86_64-unknown-linux-gnu/ LIBRARY_PATH=/opt/software/gcc-x86_64/gcc-4.4.x/lib/gcc/x86_64-unknown-linux-gnu/4.4.0/:/opt/software/gcc-x86_64/gcc-4.4.x/lib/gcc/x86_64-unknown-linux-gnu/4.4.0/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/opt/software/gcc-x86_64/gcc-4.4.x/lib/gcc/x86_64-unknown-linux-gnu/4.4.0/../../../:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-v' '-c' '-shared-libgcc' '-mtune=generic' SUCCESS -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39754
[Bug target/39783] -ftls-model can not be specified independently of -fpic/-fpie
--- Comment #4 from tom dot aernoudt at coware dot com 2009-04-16 14:52 --- That may be true, but if it would be possible to tell gcc to use the dynamic-global tls-model (or static-global) without specifying -fPIC it would again 'happen' to work, even if tls is used. I don't see a good reason why configuring these 2 settings independently of each other should be prevented. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39783
[Bug c/39755] inline memcpy() incorrectly optimized on MIPS target
--- Comment #2 from msieweke at broadcom dot com 2009-04-16 15:06 --- As mentioned in the original report, the bug doesn't exist in GCC 4.x.x. It has since been tested with GCC 3.4.4, where the bug is fixed. GCC 3.2.x - broken GCC 3.3.x - broken GCC 3.4.x - fixed GCC 4.x.x - fixed For a number of reasons, we're stuck using GCC 3.2.1 with only minor updates. I tried porting parts of the MIPS code generator from 3.4.4 into 3.2.1, but this is a larger project than it appears. I don't expect anyone to spend much time fixing this, but I would appreciate a hint about how I might approach a fix. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39755
[Bug rtl-optimization/39762] [4.4/4.5 Regression] IRA ICE with -msoft-float
--- Comment #2 from vmakarov at gcc dot gnu dot org 2009-04-16 15:16 --- Subject: Bug 39762 Author: vmakarov Date: Thu Apr 16 15:15:48 2009 New Revision: 146198 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=146198 Log: 2009-04-16 Vladimir Makarov vmaka...@redhat.com PR rtl-optimization/39762 * ira-int.h (ira_register_move_cost, ira_may_move_in_cost, ira_may_move_out_cost): Add comments about way of their usage. (ira_get_register_move_cost, ira_get_may_move_cost): New functions. * ira-conflicts.c (process_regs_for_copy): Use function ira_get_register_move_cost instead of global ira_register_move_cost. * ira-color.c (update_copy_costs, calculate_allocno_spill_cost, color_pass, move_spill_restore, update_curr_costs): Ditto. * ira-lives.c (process_single_reg_class_operands): Ditto. * ira-emit.c (emit_move_list): Ditto. * ira-costs.c (copy_cost): Don't call ira_init_register_move_cost. (record_reg_classes): Ditto. Use functions ira_get_register_move_cost and ira_get_may_move_cost instead of global vars ira_register_move_cost, ira_may_move_out_cost and ira_may_move_in_cost. (record_address_regs): Don't call ira_init_register_move_cost. Use function ira_get_may_move_cost instead of global ira_may_move_in_cost. (process_bb_node_for_hard_reg_moves): Use function ira_get_register_move_cost instead of global ira_register_move_cost. (ira_costs): Don't call ira_init_register_move_cost. Modified: trunk/gcc/ChangeLog trunk/gcc/ira-color.c trunk/gcc/ira-conflicts.c trunk/gcc/ira-costs.c trunk/gcc/ira-emit.c trunk/gcc/ira-int.h trunk/gcc/ira-lives.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39762
[Bug tree-optimization/30930] [4.3 Regression] vector can cause to create an extra variable, DECL_GIMPLE_REG_P not recomputed
--- Comment #16 from pinskia at gcc dot gnu dot org 2009-04-16 15:42 --- I am no longer working on this one. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|pinskia at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30930
[Bug c++/36695] [4.3 Regression] Value-initialization of reference type is allowed.
--- Comment #10 from pinskia at gcc dot gnu dot org 2009-04-16 15:43 --- I am no longer working on this one. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|pinskia at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36695
[Bug rtl-optimization/37263] [4.3 Regression] extra code for doloop with unsigned 32bit types on LP64
--- Comment #9 from pinskia at gcc dot gnu dot org 2009-04-16 15:43 --- I am no longer working on this one. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|pinskia at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37263
[Bug rtl-optimization/37219] [4.3 Regression] fwprop1 is broken for addresses
--- Comment #8 from pinskia at gcc dot gnu dot org 2009-04-16 15:43 --- I am no longer working on this one. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|pinskia at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37219
[Bug c++/36607] [4.3 Regression] Incorrect type diagnostic on substracting casted char pointers
--- Comment #11 from pinskia at gcc dot gnu dot org 2009-04-16 15:43 --- I am no longer working on this one. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|pinskia at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36607
[Bug c++/29388] [4.3 regression] ICE with invalid nested name specifier
--- Comment #13 from pinskia at gcc dot gnu dot org 2009-04-16 15:44 --- I am no longer working on this one. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|pinskia at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29388
[Bug c/34911] [4.3 regression] ICE with vectors of bool
--- Comment #12 from pinskia at gcc dot gnu dot org 2009-04-16 15:44 --- I am no longer working on this one. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|pinskia at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34911
[Bug c/35430] [4.3 regression] ICE with complex arithmetic
--- Comment #8 from pinskia at gcc dot gnu dot org 2009-04-16 15:44 --- I am no longer working on this one. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|pinskia at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35430
[Bug tree-optimization/36891] [4.3 Regression] ICE with vector division and -ffast-math and LIM
--- Comment #10 from pinskia at gcc dot gnu dot org 2009-04-16 15:44 --- I am no longer working on this one. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|pinskia at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36891
[Bug c++/38638] [4.3 regression] ICE superfluous 'typename'
--- Comment #6 from pinskia at gcc dot gnu dot org 2009-04-16 15:45 --- I am no longer working on this one. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|pinskia at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38638
[Bug rtl-optimization/37451] Extra addition for doloop in some cases
--- Comment #6 from pinskia at gcc dot gnu dot org 2009-04-16 15:48 --- I am no longer working on this one. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|pinskia at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37451
[Bug c++/29388] [4.3 regression] ICE with invalid nested name specifier
--- Comment #14 from sje at cup dot hp dot com 2009-04-16 15:48 --- It looks like you already fixed it on the mainline, is there a reason the patch can't be backported to the 4.3 branch and the defect closed? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29388
[Bug c/39755] inline memcpy() incorrectly optimized on MIPS target
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-04-16 15:56 --- Try bisecting the changes to cherry-pick the one fixing the bug. Fixed in GCC 3.4. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED Target Milestone|--- |3.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39755
[Bug c++/39365] ++ operator with volatile bool increments
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-04-16 16:04 --- Actually it is just better to check the tree code, testing the patch right now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39365
[Bug c++/36799] [c++0x] error on va_copy in -std=c++0x mode
--- Comment #7 from pinskia at gcc dot gnu dot org 2009-04-16 16:07 --- Fixed in 4.4.0. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36799
[Bug rtl-optimization/39580] [4.5 regression] Revision 145204 caused libgomp.c++/collapse-2.C
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-04-16 16:13 --- This looks like better optimizations is causing a latent bug in the selective-scheduling to show up. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Component|middle-end |rtl-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39580
[Bug bootstrap/35628] gcc-4.3.0 fails to build, mpfr problem, libmpfr.dylib, file is not of required architecture
--- Comment #3 from aam at fastmail dot fm 2009-04-16 16:18 --- export ABI=32 I used this to tell GMP and MPFR that I wanted 32-bit libraries, which GCC 4.3.3 seemed to need rather than the default of 64-bit libraries which causes the GCC configure script to fail to detect the proper version of MPFR. This worked for me on Darwin 9.6.1. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35628
[Bug target/23322] [4.3 regression] performance regression
--- Comment #36 from pinskia at gcc dot gnu dot org 2009-04-16 16:22 --- Fixed via Ira so marking as such. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |NEW Known to work|2.95.4 |2.95.4 4.4.0 4.5.0 Last reconfirmed|2008-02-05 16:18:23 |2009-04-16 16:22:11 date|| Summary|[4.3/4.4/4.5 regression]|[4.3 regression] performance |performance regression |regression http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23322
[Bug c++/15480] ICE with sizeof(T().f()) as template parameter in function resolution
--- Comment #10 from pinskia at gcc dot gnu dot org 2009-04-16 16:35 --- Fixed at least on the trunk. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15480
[Bug c++/17395] [4.5 Regression] Incorrect lookup for parameters
--- Comment #8 from pinskia at gcc dot gnu dot org 2009-04-16 16:50 --- The testcase from comment #7 is correctly rejected but the testcase from comment #0 is ICEing now which makes this a regression as 4.4.0 20090101 accepted it. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||ice-on-valid-code Known to fail||4.5.0 Summary|Incorrect lookup for|[4.5 Regression] Incorrect |parameters |lookup for parameters Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17395
[Bug c++/5023] Error declaring constructor of template class specialization as friend
--- Comment #6 from pinskia at gcc dot gnu dot org 2009-04-16 16:53 --- (In reply to comment #4) But this is valid and is rejected by gcc but accpected by ICC: This is now accepted on the trunk. friend Sint::Sint(); is still rejected but I don't know if that is valid or not. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5023
[Bug rtl-optimization/39762] [4.4 Regression] IRA ICE with -msoft-float
--- Comment #3 from jakub at gcc dot gnu dot org 2009-04-16 16:55 --- Vlad, do you plan to commit to 4.4 branch as well? -- jakub at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.4/4.5 Regression] IRA ICE|[4.4 Regression] IRA ICE |with -msoft-float |with -msoft-float http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39762
[Bug fortran/35423] Implement OpenMP workshare
--- Comment #5 from jakub at gcc dot gnu dot org 2009-04-16 16:59 --- http://gcc.gnu.org/ml/gcc-patches/2009-04/msg01249.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35423
[Bug c++/28766] compound literal expression vs templates
--- Comment #5 from pinskia at gcc dot gnu dot org 2009-04-16 17:02 --- Fixed in at least 4.4.0 and above. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28766
[Bug c++/12672] Evals template defaults args that it should not
--- Comment #5 from igodard at pacbell dot net 2009-04-16 17:02 --- Wow! Six years and counting! This might be my oldest outstanding bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12672
[Bug c++/28766] compound literal expression vs templates
--- Comment #6 from pinskia at gcc dot gnu dot org 2009-04-16 17:03 --- Mine to commit the testcase. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28766
[Bug c++/28766] compound literal expression vs templates
--- Comment #7 from pinskia at gcc dot gnu dot org 2009-04-16 17:07 --- Fixed so closing. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28766
[Bug c++/28766] compound literal expression vs templates
--- Comment #8 from pinskia at gcc dot gnu dot org 2009-04-16 17:07 --- Subject: Bug 28766 Author: pinskia Date: Thu Apr 16 17:07:06 2009 New Revision: 146203 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=146203 Log: 2009-04-16 Andrew Pinski pins...@gmail.com PR C++/28766 * g++.dg/ext/complit11.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/ext/complit11.C Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28766
[Bug c++/17570] Extension to incorporate default parameters in signature of templates breaks valid program
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-04-16 17:08 --- Fixed in at least 4.4.0. Mine to commit the testcase. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Known to work||4.4.0 4.5.0 Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17570
[Bug c++/17570] Extension to incorporate default parameters in signature of templates breaks valid program
--- Comment #5 from pinskia at gcc dot gnu dot org 2009-04-16 17:16 --- Fixed so closing as such. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17570
[Bug c++/17570] Extension to incorporate default parameters in signature of templates breaks valid program
--- Comment #6 from pinskia at gcc dot gnu dot org 2009-04-16 17:16 --- Subject: Bug 17570 Author: pinskia Date: Thu Apr 16 17:15:59 2009 New Revision: 146206 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=146206 Log: 2009-04-16 Andrew Pinski pins...@gmail.com PR C++/17570 * g++.dg/template/defarg11.C: New test. Added: trunk/gcc/testsuite/g++.dg/template/defarg11.C Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17570
[Bug fortran/39772] SIZE intrinsic ignores optional KIND argument
--- Comment #6 from kargl at gcc dot gnu dot org 2009-04-16 17:31 --- well, that was an inconvenient goose chase. (Note to self: always check the Standard). I'm tempted to close this with INVALID because the F95 Standard explicitly states that SIZE() has a Result Characteristics. Default integer scalar. and it further states A program is prohibited from invoking an intrinsic procedure under circumstances where a value to be returned in a subroutine argument or function result is outside the range of values representable by objects of the specified type and type parameters. Thus, it is the users' responsibility to catch a possible problem. INTEGER*8 :: N INTEGER, DIMENSION(:), ALLOCATABLE :: data N=2_8**32 write(6,*) N ALLOCATE(data(N)) if (n, int(huge(1), 8)) then write(6,*) SIZE(data,1) end if END That being said, I'm changing this from an enhancement request to a wrong-code bug because gfortran has grown support for the F2003 standards' optional kind argument. F2003 standard has Result Characteristics. Integer scalar. If KIND is present, the kind type parameter is that specified by the value of KIND; otherwise the kind type parameter is that of default integer type. NTEGER*8 :: N INTEGER, DIMENSION(:), ALLOCATABLE :: data N=2_8**32 write(6,*) N ALLOCATE(data(N)) write(6,*) SIZE(data,kind=8) END REMOVE:kargl[253] gfc4x -o z -fdump-tree-original d.f90 REMOVE:kargl[254] ./z 4294967296 0 This is clearly wrong, and -fdump-tree-original shows that the computation of size is doen in INTEGER*4. -- kargl at gcc dot gnu dot org changed: What|Removed |Added Severity|enhancement |normal Priority|P3 |P4 Last reconfirmed|2009-04-15 17:43:49 |2009-04-16 17:31:44 date|| Summary|add a correctness check for |SIZE intrinsic ignores |the size intrinsic to - |optional KIND argument |fbounds-check | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39772
[Bug c++/39728] C++ diagnostic for private operator= is voluminous and unhelpful
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-04-16 18:22 --- I think libstdc++ include pathes make the error message useless but if the user code had the same walking back, I think the user would say this is more useful message than what is recommended in comment #0 (at least by default). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Keywords||diagnostic http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39728
[Bug c++/39729] C++ does not name a type error message can be misleading
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-04-16 18:24 --- First there are a couple of issues here: 1) accepts invalid code: using namespace std; 2) foo.cc:3: error: ifstream does not name a type Yes that should change if ifstream is not defined at all but we still want to give the error message we currently give for: int ifstream; ifstream x; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39729
[Bug c++/39729] C++ does not name a type error message can be misleading
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-04-16 18:24 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||diagnostic Last reconfirmed|-00-00 00:00:00 |2009-04-16 18:24:59 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39729
[Bug c++/39730] C++ incomplete type error can be misleading
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-04-16 18:26 --- foo.cc:6: error: std::ifstream was declared but not defined This is even more confusing to me. As incomplete types are understood easier than just being declared and not defined. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39730
[Bug middle-end/39731] Separate warning classes for maybe-uninitialized and known-uninitialized variables.
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-04-16 18:28 --- The problem is that GCC does not give an error It can't give an error for that code as it is only runtime undefined and it does not have to be invoked at runtime (i.e. the function is not called). -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39731
[Bug middle-end/39731] Separate warning classes for maybe-uninitialized and known-uninitialized variables.
--- Comment #2 from scottwood at freescale dot com 2009-04-16 18:30 --- (In reply to comment #1) The problem is that GCC does not give an error It can't give an error for that code as it is only runtime undefined and it does not have to be invoked at runtime (i.e. the function is not called). -- Pinski Yes, that was pointed out in the thread -- hence the request simply being a separation of warning classes. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39731
[Bug target/39258] No ABI warnings on __m128i when SSE is disabled
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-04-16 18:33 --- Stop setting the target milestone unless it is a regression. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.5.0 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39258
[Bug middle-end/39315] Unaligned move used on aligned stack variable
--- Comment #10 from pinskia at gcc dot gnu dot org 2009-04-16 18:33 --- Stop setting the target milestone unless it is a regression. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.5.0 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39315
[Bug target/39146] Unnecessary stack alignment
--- Comment #18 from pinskia at gcc dot gnu dot org 2009-04-16 18:33 --- Stop setting the target milestone unless it is a regression. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.5.0 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39146
[Bug inline-asm/39590] inline asm %z on amd64 says ll instead of q
--- Comment #11 from pinskia at gcc dot gnu dot org 2009-04-16 18:34 --- Stop setting the target milestone unless it is a regression. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.5.0 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39590
[Bug target/39323] MAX_OFILE_ALIGNMENT in elfos.h is too big
--- Comment #6 from pinskia at gcc dot gnu dot org 2009-04-16 18:34 --- Stop setting the target milestone unless it is a regression. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.5.0 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39323
[Bug fortran/39782] [4.3/4.4/4.5 Regression] IO depends on uninitialised value
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-04-16 18:37 --- Confirmed: ==21080== Conditional jump or move depends on uninitialised value(s) ==21080==at 0x4BD8A78: finalize_transfer (transfer.c:3147) -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-04-16 18:37:09 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39782
[Bug tree-optimization/39746] [4.5 Regression] Fail pr34513.c and pr34513.C at -O1 and above
--- Comment #12 from pinskia at gcc dot gnu dot org 2009-04-16 18:45 --- stw %r3,RR'shrd.1301-$global$(%r1) .CALL bl GOMP_atomic_end,%r2 nop .CALL bl GOMP_barrier,%r2 nop comib,= 4,%r3,L$0006 ldw -84(%r30),%r2 So r3 after the call to GOMP_barrier contains the old value of shrd which seems wrong. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-04-16 18:45:47 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39746
