Re: Help-The possible places where insn is splitted in greg pass
Qifei Fan wrote: But insn#479 is not recognized by recog() in insn-recog.c and the compilation failed. (recog only recognizes RTL defined in md, right?) Here the backtrace is reload---cleanup_subreg_operands---extract_insn_cached---extract_insn-= --recog_memoized---recog. There is no machine instruction(r3=3Dr1*4+r2) match the pattern of insn#479. Though there is pattern r3=3Dmem(r1*4+r2). I don=92t quite understand the generation of reload information. There's two issues here. The first issue is that reload makes the fundamental assumption that everything that is a valid address, can be loaded into a register as well, if necessary. On many platforms this is true, either because there is some sort of load address instruction, or because the form of valid addresses matches standard arithmetic instruction patterns. Reload will simply emit a naked set of some register to the address -- if the back-end doesn't support that, you'll get the failure you saw. If this doesn't work on your particular platform, you could either try to set things up so that reload never thinks it needs to reload an address (but this may be difficult to achieve). The safe option would be to tell reload how to achieve computing an address by providing a secondary reload pattern. See e.g. s390_secondary_reload (in config/s390/s390.c) and the associated reloadmode_plus pattern. The second issue is as you notice here: Actually the second reload is not needed if there is already the first relo= ad. If (plus:SI (reg/f:SI 16 SP) (const_int 96 [0x60]) is replaced by (reg:SI 12 a12), then (plus:SI (mult:SI (reg:SI 9 a9 [204]) (const_int 4 [0x4])) (reg:SI 12 a12) ) is a valid memory address. But in function find_reloads, I can=92t find the related code that deciding whether the second reload should be generated by regarding the previous reload. The function is too complex. :-( The first reload, loading sp + 96 into a register, is generated from within find_reloads_address. After this is done, it is assumed that the address is now valid. However, something else later in find_reloads apparently assumes there is still some problem with the operand, and decides to reload the whole address. It is hard to say exactly what the problem is, without seeing the insn constraints, but the most likely cause seems to be that this instruction pattern does not have a general m constraint, but a more restricted memory constraint. If this is the case, the back-end procedure called to verify the constraint probably rejects it. This runs into another fundamental assumption reload makes: it assumes such procedures take other actions done by reload into account implicitly. This means the constraint checker ought to *accept* addresses of the form reg*const + (sp + const) because it ought to know that reload will already load the (sp + const) into a register anyway. If this is *not* the case, please send me the instruction pattern and constraints for the insn pattern that matched insn 320 before reload so I can investigate in more detail. (Please note that I'm currently travelling with restricted access to email, so it might be a couple of days before I'm able to reply; sorry ...) Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE ulrich.weig...@de.ibm.com
Re: [gcc] can't build current trunk: ar: .libs/libgomp.lib: File format not recognized
Should have gone here I suppose... 2010/1/25 Christian Joensson: Hi Dave. I see you're busy with your cygwin improvement branch... however, I just want to give you a heads up, as for a some time, I can't build gcc trunk, there's something with libgomp that's quite wrong. libtool: link: /usr/local/src/trunk/objdir/./gcc/xgcc -B/usr/local/src/trunk/objdir/./gcc/ -B/usr/local/gnu/i686-pc-cygwin/bin/ -B/usr/local/gnu/i686-pc-cygwin/lib/ -isystem /usr/local/gnu/i686-pc-cygwin/include -isystem /usr/local/gnu/i686-pc-cygwin/sys-include -shared .libs/alloc.o .libs/barrier.o .libs/critical.o .libs/env.o .libs/error.o .libs/iter.o .libs/iter_ull.o .libs/loop.o .libs/loop_ull.o .libs/ordered.o .libs/parallel.o .libs/sections.o .libs/single.o .libs/task.o .libs/team.o .libs/work.o .libs/lock.o .libs/mutex.o .libs/proc.o .libs/sem.o .libs/bar.o .libs/ptrlock.o .libs/time.o .libs/fortran.o .libs/affinity.o -pthread -Wl,-O1 -o .libs/libgomp-1.dll -Wl,--enable-auto-image-base -Xlinker --out-implib -Xlinker .libs/libgomp-1.dll xgcc: unrecognized option '-pthread' Creating library file: .libs/libgomp-1.dll libtool: link: (cd .libs rm -f libgomp.lib ln -s libgomp-1.dll libgomp.lib) libtool: link: ar rc .libs/libgomp.lib alloc.o barrier.o critical.o env.o error.o iter.o iter_ull.o loop.o loop_ull.o ordered.o parallel.o sections.o single.o task.o team.o work.o lock.o mutex.o proc.o sem.o bar.o ptrlock.o time.o fortran.o affinity.o ar: .libs/libgomp.lib: File format not recognized make[5]: *** [libgomp.la] Error 1 make[5]: Leaving directory `/usr/local/src/trunk/objdir/i686-pc-cygwin/libgomp' make[4]: *** [all-recursive] Error 1 make[4]: Leaving directory `/usr/local/src/trunk/objdir/i686-pc-cygwin/libgomp' make[3]: *** [all] Error 2 make[3]: Leaving directory `/usr/local/src/trunk/objdir/i686-pc-cygwin/libgomp' make[2]: *** [all-stage1-target-libgomp] Error 2 make[2]: Leaving directory `/usr/local/src/trunk/objdir' make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory `/usr/local/src/trunk/objdir' make: *** [all] Error 2 I can't say for sure when this started happening, for me, 156188 seems to work, and 156189 does not. -- Cheers, /ChJ
strict aliasing violation
I have a hash function hash(T v) overloaded for
all integral types. I want to provide a variant for
float and double, which should work as follows:
take the floating-point value, treat its binary
representation as uint32_t/uint64_t and use
the result as a parameter for an integral hash().
However, GCC warns me about strict aliasing
rules violation, which is technically correct, but
in this case is intended. How do I perform this
conversion ina GCC-friendly way? Even that
produces a warning:
inline hash_type hash(float v) {
return hash(*reinterpret_castconst
std::uint32_t*(reinterpret_castconst char*(v)));
}
but I expected char* to be allowed to alias anything.
Best regards
Piotr Wyderski
porting GCC to a micro with a very limited addressing mode --- what to write in LEGITIMATE_ADDRESS, LEGITIMIZE_ADDRESS and micro.md ?!
Hi everyone,
I am porting GCC to a custom 16-bit microcontroller with very limited
addressing modes. Basically, it can only load/store using a (general
purpose) register as the address, without any offset:
LOAD (R2) R1; load R1 from memory at address (R2)
STORE R1 (R2) ; store R1 to memory at address (R2)
As far as I can understand, this is more limited than the current
architectures supported by GCC that I found in the current gcc/config/*.
Since for my port I started modifying a MIPS target (from the tutorials
by IIT Bombay http://www.cse.iitb.ac.in/grc/ - great work guys!), the
GCC still generates code like:
sw R15, 0(R13)
sw R13, -2(R13)
sw R14, -4(R13)
...
lw R14, -4(R13)
lw R15, 0(R13)
Now, in order to restrict the addressing mode, I want to force GCC to
compute the address and store it in a register, then generate the
instructions above to LOAD/STORE in memory. Thus I tried to fiddle with
LEGITIMATE_ADDRESS() and LEGITIMIZE_ADDRESS(), but the compilation of a
simple C program like:
void foobar(int par1, int par2, int parN)
{
int a, b, c;
a = -1;
b = -65535;
c = 0xabcd;
}
fails with
foobar7.c:11: internal compiler error: in change_address_1, at
emit-rtl.c:1800
Please submit a full bug report,
The same program gets compiled with the lw/sw above if I replace 0 with
1 in legitimate_address() below, at the comment /* reject/accept*/.
What should I do? How the addressing mode(s) are managed in the md files
and the LEGITxxx_ADDRESS() macros ? The GCC manual is not very clear on
this... Is there any other architecture/documentation I should look at ?
Thanks,
Sergio
===
Here follows a fragment of my micro.c with the C implementations of the
LEGITIMATE_ADDRESS() and LEGITIMIZE_ADDRESS() macros:
-
int
legitimate_address2(enum machine_mode MODE,rtx X)
{
rtx op1,op2;
if(CONSTANT_ADDRESS_P(X))
{
return 1;
}
if(GET_CODE(X)==REG non_strict_base_reg(REGNO(X)))
{
return 1;
}
if(GET_CODE(X)==PLUS) /* is it offset+(Rx) ?! */
{
puts (GET_CODE(X)==PLUS );
op1=XEXP(X,0);
op2=XEXP(X,1);
if(GET_CODE(op1)==REG CONSTANT_ADDRESS_P(op2)
non_strict_base_reg(REGNO(op1)))
{
return 0; /* reject / accept */
}
if(GET_CODE(op2)==REG CONSTANT_ADDRESS_P(op1)
non_strict_base_reg(REGNO(op2)))
{
return 0; /* reject / accept */
}
}
/* reject all other cases, too */
puts (legitimate_address2() - end - ret 0/NO);
return 0;
}
rtx
legitimize_address(rtx X,rtx OLDX, enum machine_mode MODE)
{
rtx op1,op2,op;
op=NULL;
if(memory_address_p(MODE,X))
return X;
if(GET_CODE(X)==MEM !no_new_pseudos)
op = force_reg(MODE,X);
else if ( GET_CODE(X)==PLUS !no_new_pseudos)
{
puts(GET_CODE(X)==PLUS !no_new_pseudos !);
op1=XEXP(X,0);
op2=XEXP(X,1);
if(GET_CODE(op1)==REG !CONSTANT_ADDRESS_P(op2))
{
op=force_reg(MODE,X);
}
else if(GET_CODE(op2)==REG !CONSTANT_ADDRESS_P(op1))
{
op=force_reg(MODE,X);
}
else /* HACK */
{
op=force_reg(MODE,X);
}
-
/* Here is another HACK attempt, now disabled (commented), inspired by
http://gcc.gnu.org/ml/gcc/2001-07/msg01513.html, but this is not
working, either */
else if ( (GET_CODE (op1)== REG) (GET_CODE (op2) ==
CONST_INT) )
{
op1 = force_reg (MODE, op1);
op = force_reg (MODE, gen_rtx_PLUS (MODE, op1, op2));
}
-
}
if(op!=NULL memory_address_p(MODE,op))
{
return op; /* if we rewrote the expression */
}
return X; /* otherwise original */
}
-
Here is a fragment of micro.md with the definitions of the movXX,
load and store patterns:
(define_expand movhi
[(set (match_operand:HI 0 nonimmediate_operand )
(match_operand:HI 1 general_operand )
)]
{
if(GET_CODE(operands[0])==MEM GET_CODE(operands[1])!=REG)
{
if(!no_new_pseudos) {
operands[1]=force_reg(HImode,operands[1]);
}
}
}
)
;;Load patterns
(define_insn
Re: strict aliasing violation
Piotr Wyderski piotr.wyder...@gmail.com writes:
However, GCC warns me about strict aliasing
rules violation, which is technically correct, but
in this case is intended. How do I perform this
conversion ina GCC-friendly way? Even that
produces a warning:
inline hash_type hash(float v) {
return hash(*reinterpret_castconst
std::uint32_t*(reinterpret_castconst char*(v)));
}
but I expected char* to be allowed to alias anything.
Only when used as the type to access the object, but you access it as
uint32_t. The intermediate cast is irrelevant for aliasing
consideration.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
And now for something completely different.
Re: strict aliasing violation
On Mon, Jan 25, 2010 at 1:24 PM, Piotr Wyderski
piotr.wyder...@gmail.com wrote:
I have a hash function hash(T v) overloaded for
all integral types. I want to provide a variant for
float and double, which should work as follows:
take the floating-point value, treat its binary
representation as uint32_t/uint64_t and use
the result as a parameter for an integral hash().
However, GCC warns me about strict aliasing
rules violation, which is technically correct, but
in this case is intended. How do I perform this
conversion ina GCC-friendly way? Even that
produces a warning:
inline hash_type hash(float v) {
return hash(*reinterpret_castconst
std::uint32_t*(reinterpret_castconst char*(v)));
}
but I expected char* to be allowed to alias anything.
But your access is via std::uint32_t *, not char. Use a
union like
union { float f; uint32 i; } u = {.f = v};
return u.i;
Richard.
Best regards
Piotr Wyderski
Re: [gcc] can't build current trunk: ar: .libs/libgomp.lib: File format not recognized
Quoting Christian Joensson christian.joens...@gmail.com:
-Xlinker .libs/libgomp-1.dll
xgcc: unrecognized option '-pthread'
Oops, we can't actually always bootstrap libgomp - we shouldn't try if it's
not in target_configdirs.
Does the cygwin build work with the attached patch?
2010-01-23 Joern Rennecke amyl...@spamcop.net
PR libstdc++/36101, PR libstdc++/42813
* configure.ac (bootstrap_target_libs): Make inclusion of
target-libgomp conditional on libgomb being in target_configdirs.
* configure: Regenerate.
Index: configure.ac
===
--- configure.ac(revision 156191)
+++ configure.ac(working copy)
@@ -1744,7 +1744,7 @@ fi
stage1_languages=,c,
# Target libraries that we bootstrap.
-bootstrap_target_libs=,target-libgcc,target-libgomp,
+bootstrap_target_libs=,target-libgcc,
# Figure out what language subdirectories are present.
# Look if the user specified --enable-languages=...; if not, use
@@ -2540,6 +2540,11 @@ fi
target_configdirs=`echo ${target_configdirs} | sed -e 's/target-//g'`
build_configdirs=`echo ${build_configdirs} | sed -e 's/build-//g'`
+# If we are building libgomp, bootstrap it.
+if echo ${target_configdirs} | grep libgomp /dev/null 21 ; then
+ bootstrap_target_libs=${bootstrap_target_libs}target-libgomp,
+fi
+
# Determine whether gdb needs tk/tcl or not.
# Use 'maybe' since enable_gdbtk might be true even if tk isn't available
# and in that case we want gdb to be built without tk. Ugh!
Index: configure
===
--- configure (revision 156191)
+++ configure (working copy)
@@ -6545,7 +6545,7 @@ fi
stage1_languages=,c,
# Target libraries that we bootstrap.
-bootstrap_target_libs=,target-libgcc,target-libgomp,
+bootstrap_target_libs=,target-libgcc,
# Figure out what language subdirectories are present.
# Look if the user specified --enable-languages=...; if not, use
@@ -7394,6 +7394,11 @@ fi
target_configdirs=`echo ${target_configdirs} | sed -e 's/target-//g'`
build_configdirs=`echo ${build_configdirs} | sed -e 's/build-//g'`
+# If we are building libgomp, bootstrap it.
+if echo ${target_configdirs} | grep libgomp /dev/null 21 ; then
+ bootstrap_target_libs=${bootstrap_target_libs}target-libgomp,
+fi
+
# Determine whether gdb needs tk/tcl or not.
# Use 'maybe' since enable_gdbtk might be true even if tk isn't available
# and in that case we want gdb to be built without tk. Ugh!
Re: strict aliasing violation
On Mon, Jan 25, 2010 at 02:19:04PM +0100, Richard Guenther wrote:
On Mon, Jan 25, 2010 at 1:24 PM, Piotr Wyderski
piotr.wyder...@gmail.com wrote:
I have a hash function hash(T v) overloaded for
all integral types. I want to provide a variant for
float and double, which should work as follows:
take the floating-point value, treat its binary
representation as uint32_t/uint64_t and use
the result as a parameter for an integral hash().
However, GCC warns me about strict aliasing
rules violation, which is technically correct, but
in this case is intended. How do I perform this
conversion ina GCC-friendly way? Even that
produces a warning:
inline hash_type hash(float v) {
return hash(*reinterpret_castconst
std::uint32_t*(reinterpret_castconst char*(v)));
}
but I expected char* to be allowed to alias anything.
But your access is via std::uint32_t *, not char. Use a
union like
union { float f; uint32 i; } u = {.f = v};
return u.i;
Nope, that is not allowed either.
What probably would work is to use memcpy() to copy the contents
of an object of type float into another object of type uint32_t and
then use the value of that object. As long as uint32_t does not have
any trap representations that should be safe.
--
Insert your favourite quote here.
Erik Trulsson
ertr1...@student.uu.se
Re: Mangled Typedef names in GNU 4.1.2 DWARF data?
The use of anonymous structure does seem to be the problem. I also missed the
fact that the TYPE_DEF DIE is missing from the DWARF data. If the TYPE
_DEF DIE was in the DWARF data, I could still parse the anonymous type.
Do you think the TYPE_DEF DIE should be part of the output? Is this a GNU
bug or just an unsupported feature?
Thanks.
--- On Fri, 1/22/10, Michael Eager ea...@eagercon.com wrote:
From: Michael Eager ea...@eagercon.com
Subject: Re: Mangled Typedef names in GNU 4.1.2 DWARF data?
To: Ron Louzon louz...@yahoo.com
Cc: gcc@gcc.gnu.org
Date: Friday, January 22, 2010, 4:39 PM
Ron Louzon wrote:
The GNU 4.1.2 C++ compiler is mangling typedef names
to the point that they are not retrievable from the DWARF
data.
For example, the type BASE_UNION is defined as
typedef union
{
char ch;
int iVal;
long IVal;
} BASE_UNION;
This is an anonymous union which is typedef'ed to
BASE_UNION.
The GNU 4.1.2 compiler generates the following DWARF
data for this type
11279: Abbrev Number: 35
(DW_TAG_union_type)
127a
DW_AT_sibling :
12a8
127e
DW_AT_name :
$_4
1282
DW_AT_byte_size :
4
1283
DW_AT_decl_file :
35
1284
DW_AT_decl_line :
29
This doesn't look correct. The union has no name, so
DW_AT_name should
not be present or should be null. From the DWARF v.3
spec:
2.15 Identifier Names
Any debugging information entry representing a
program entity that has been
given a name may have a DW_AT_name attribute, whose
value is a string
representing the name as it appears in the source
program. A debugging
information entry containing no name attribute, or
containing a name attribute
whose value consists of a name containing a single
null byte, represents a
program entity for which no name was given in the
source.
21285: Abbrev Number: 36
(DW_TAG_member)
1286
DW_AT_name :
ch
1289
DW_AT_decl_file :
35
128a
DW_AT_decl_line :
30
128b
DW_AT_type :
c0d
2128f: Abbrev Number: 36
(DW_TAG_member)
1290
DW_AT_name :
iVal
1295
DW_AT_decl_file :
35
1296
DW_AT_decl_line :
31
1297
DW_AT_type :
b7f
2129b: Abbrev Number: 36
(DW_TAG_member)
129c
DW_AT_name :
IVal
12a1
DW_AT_decl_file :
35
12a2
DW_AT_decl_line :
32
12a3
DW_AT_type :
b86
Notice that the union name has been changed to $_4
in DIE 1279.
The GNU 3.4.4 compiler generates the following DWARF
data from the same source code:
111d0: Abbrev Number: 27
(DW_TAG_union_type)
DW_AT_sibling
: 123f
DW_AT_name
: (indirect string, offset: 0x6e):
BASE_UNION
DW_AT_byte_size :
4
DW_AT_decl_file :
3
DW_AT_decl_line :
29
This is similarly incorrect. The union has no name.
Why is GNU 4.1.2 generating the mangled type name and
how do I correct this to generate the real type name?
A better question might by why there is no DW_TAG_typedef
DIE which looks like
DW_TAG_typedef
DW_AT_name: BASE_UNION
DW_AT_type: 1279
BTW gcc-4.3.2 generates
DW_AT_name: anonymous union
which is also incorrect.
-- Michael eager ea...@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: strict aliasing violation
On 01/25/2010 02:42 PM, Erik Trulsson wrote:
On Mon, Jan 25, 2010 at 02:19:04PM +0100, Richard Guenther wrote:
On Mon, Jan 25, 2010 at 1:24 PM, Piotr Wyderski
piotr.wyder...@gmail.com wrote:
I have a hash function hash(T v) overloaded for all integral
types. I want to provide a variant for float and double, which
should work as follows: take the floating-point value, treat its
binary representation as uint32_t/uint64_t and use the result as a
parameter for an integral hash().
However, GCC warns me about strict aliasing rules violation, which
is technically correct, but in this case is intended. How do I
perform this conversion ina GCC-friendly way? Even that produces a
warning:
inline hash_type hash(float v) {
return hash(*reinterpret_castconst
std::uint32_t*(reinterpret_castconst char*(v)));
}
but I expected char* to be allowed to alias anything.
But your access is via std::uint32_t *, not char. Use a
union like
union { float f; uint32 i; } u = {.f = v};
return u.i;
Nope, that is not allowed either.
Of course it is allowed. It's a legitimate gcc extension, and it's
supported by many other compilers too.
Andrew.
Re: porting GCC to a micro with a very limited addressing mode --- what to write in LEGITIMATE_ADDRESS, LEGITIMIZE_ADDRESS and micro.md ?!
On Mon, Jan 25, 2010 at 01:34:09PM +0100, Sergio Ruocco wrote: Hi everyone, I am porting GCC to a custom 16-bit microcontroller with very limited addressing modes. Basically, it can only load/store using a (general purpose) register as the address, without any offset: LOAD (R2) R1; load R1 from memory at address (R2) STORE R1 (R2) ; store R1 to memory at address (R2) As far as I can understand, this is more limited than the current architectures supported by GCC that I found in the current gcc/config/*. The Itanium (ia64) has the same limited choice of addressing modes. Gabriel
Re: strict aliasing violation
On Mon, Jan 25, 2010 at 3:42 PM, Erik Trulsson ertr1...@student.uu.se wrote:
On Mon, Jan 25, 2010 at 02:19:04PM +0100, Richard Guenther wrote:
On Mon, Jan 25, 2010 at 1:24 PM, Piotr Wyderski
piotr.wyder...@gmail.com wrote:
I have a hash function hash(T v) overloaded for
all integral types. I want to provide a variant for
float and double, which should work as follows:
take the floating-point value, treat its binary
representation as uint32_t/uint64_t and use
the result as a parameter for an integral hash().
However, GCC warns me about strict aliasing
rules violation, which is technically correct, but
in this case is intended. How do I perform this
conversion ina GCC-friendly way? Even that
produces a warning:
inline hash_type hash(float v) {
return hash(*reinterpret_castconst
std::uint32_t*(reinterpret_castconst char*(v)));
}
but I expected char* to be allowed to alias anything.
But your access is via std::uint32_t *, not char. Use a
union like
union { float f; uint32 i; } u = {.f = v};
return u.i;
Nope, that is not allowed either.
It's a GCC extension sanctioned by the latest revision of the C99
standard.
What probably would work is to use memcpy() to copy the contents
of an object of type float into another object of type uint32_t and
then use the value of that object. As long as uint32_t does not have
any trap representations that should be safe.
At least 6.5/6 does not explicitly suggest this. But it happens
to work with GCC as well.
Richard.
Re: strict aliasing violation
Andrew Haley wrote:
union { float f; uint32 i; } u = {.f = v};
return u.i;
Nope, that is not allowed either.
Of course it is allowed. It's a legitimate gcc extension, and it's
supported by many other compilers too.
It's a C extension, according to the documentation.
In C++ mode (-std=gnu++0x) the compiler does not
understand the u = {.f = v} statement. Is it a feature
or a bug? ;-)
Best regards
Piotr Wyderski
Re: Mangled Typedef names in GNU 4.1.2 DWARF data?
Ron Louzon wrote: The use of anonymous structure does seem to be the problem. I also missed the fact that the TYPE_DEF DIE is missing from the DWARF data. If the TYPE _DEF DIE was in the DWARF data, I could still parse the anonymous type. Do you think the TYPE_DEF DIE should be part of the output? Is this a GNU bug or just an unsupported feature? It looks like a GCC bug to me. GCC does generate DW_TAG_typedef for other typedefs. -- Michael Eagerea...@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Re: [gcc] can't build current trunk: ar: .libs/libgomp.lib: File format not recognized
On 01/25/2010 03:04 PM, Joern Rennecke wrote: Quoting Christian Joensson christian.joens...@gmail.com: -Xlinker .libs/libgomp-1.dll xgcc: unrecognized option '-pthread' Oops, we can't actually always bootstrap libgomp - we shouldn't try if it's not in target_configdirs. Ok. Paolo
Re: [gcc] can't build current trunk: ar: .libs/libgomp.lib: File format not recognized
On 25/01/2010 14:04, Joern Rennecke wrote: Quoting Christian Joensson christian.joens...@gmail.com: -Xlinker .libs/libgomp-1.dll xgcc: unrecognized option '-pthread' Oops, we can't actually always bootstrap libgomp - we shouldn't try if it's not in target_configdirs. Does the cygwin build work with the attached patch? Was this question and/or patch inspired by the unrecognized option -pthread warning above? Only we've always gotten that on cygwin and it's always been harmless up til now. (I'm not up-to-date with head, right now I'm still on r.156105 where the problem apparently arose at r.156189; I'll update to head and get a build going.) cheers, DaveK
Re: Support for export keyword to use with C++ templates ?
Timothy Madden terminato...@gmail.com writes: On Fri, Jan 22, 2010 at 2:24 AM, Ian Lance Taylor i...@google.com wrote: Timothy Madden terminato...@gmail.com writes: Why is it so hard to store template definitions (and the set of symbols visible to them) in an object file, probably as a representation of the parsed template source tree ? I recommend reading Why We Can't Afford Export. I have seen that paper in the link, N1426, and I find it to be biased against export ... It may be biased, but I think it does a nice job of explaining why it is so hard to store template definitions and the set of symbols visible to them. g++ is free software. A clean implementation of export would certainly be accepted. All it takes is for somebody to write one. I know that seems like a non-answer, but as far as I can tell there is currently no constituency for adding export to g++. It's not something which people routinely complain about. There are C++ frontend issues which people do routinely complain about, such as bad error messages and compilation speed, and gcc developers do work on those areas. Ian
Re: [gcc] can't build current trunk: ar: .libs/libgomp.lib: File format not recognized
Quoting Dave Korn dave.korn.cyg...@googlemail.com: On 25/01/2010 14:04, Joern Rennecke wrote: Quoting Christian Joensson christian.joens...@gmail.com: -Xlinker .libs/libgomp-1.dll xgcc: unrecognized option '-pthread' Oops, we can't actually always bootstrap libgomp - we shouldn't try if it's not in target_configdirs. Does the cygwin build work with the attached patch? Was this question and/or patch inspired by the unrecognized option -pthread warning above? Well, I though the reason why you ended up with an unrecognized type libgomp-1.dll was that this diagnostic indicatde a serious problem. Only we've always gotten that on cygwin and it's always been harmless up til now. So how is a build with r156189 different from a build with provious revision? (I'm not up-to-date with head, right now I'm still on r.156105 where the problem apparently arose at r.156189; I'll update to head and get a build going.) I've now committed the patch as r156218, but we'd still like to know if that fixes cygwin builds.
Re: porting GCC to a micro with a very limited addressing mode --- what to write in LEGITIMATE_ADDRESS, LEGITIMIZE_ADDRESS and micro.md ?!
Gabriel Paubert wrote: On Mon, Jan 25, 2010 at 01:34:09PM +0100, Sergio Ruocco wrote: Hi everyone, I am porting GCC to a custom 16-bit microcontroller with very limited addressing modes. Basically, it can only load/store using a (general purpose) register as the address, without any offset: LOAD (R2) R1; load R1 from memory at address (R2) STORE R1 (R2) ; store R1 to memory at address (R2) As far as I can understand, this is more limited than the current architectures supported by GCC that I found in the current gcc/config/*. The Itanium (ia64) has the same limited choice of addressing modes. Gabriel Thanks Gabriel. I dived into the ia64 md, but it is still unclear to me how the various parts (macros, define_expand and define_insn in MD etc.) work together to force the computation of a source/dest address plus offset into a register... can anyone help me with this ? Thanks, Sergio
Re: Long paths with ../../../../ throughout
Jon Grant j...@jguk.org writes: I see that some of the files are located in the -L library directory specified, crtbegin.o, crtend.o in which case, perhaps they both do not need their full long path specified. Most linkers do not use the -L path to search for file names on the command line. Also I notice lots of duplicate parameters: Is this directory really needed twice? -L/usr/lib/gcc/i486-linux-gnu/4.3.3 -L/usr/lib/gcc/i486-linux-gnu/4.3.3 No. I would encourage you to investigate why it is happening. i tried: gcc -o t -Wl,-debug test.c, I see collect2 gets the duplicates passed to it, and then it passes it on to ld. I would have thought that if collect2 was compiled with define LINK_ELIMINATE_DUPLICATE_LDIRECTORIES it would strip out the duplicate parameters before calling ld. It does not appear to be switched on in this Ubuntu package I am using though. Is it on by default? No. It was introduced only to avoid an error in the linker in some version of SGI Irix. Generally the duplicate -L option does no harm. I was actually thinking along of the lines of eliminating it earlier in the process. Why does the directory get in there twice in the first place? To see what collect2 is doing, use -Wl,-debug If I add this to my existing command line I see there not any output: $ gcc -### -o t -Wl,-debug test.c If I change to not have -### I see it does work, not sure why. -### controls the gcc driver, not the collect2 program. So I understand that this passes -debug to collect2. As collect2 only has -v mode to display version. Would a patch to add --help to it be supported? Also could describe something about collect2's purpose at the top of that --help output. I think that ordinary uses of -Wl,--help will expect to see the --help option for the linker, not for collect2. That said, I think it would be OK to add a --help option for collect2 which issued some output and then went on to invoke the linker. 1) collect.c:scan_libraries may not find ldd, in which case it displays message on output, and returns as normal. Should it not be fatal if ldd is required? It seems to me that it gives an error message, which should cause collect2 to exit with a non-zero status. Does that not happen for you? Note that ldd is only required on HP/UX. 2) in collect2.c:main -debug is checked, and variable debug set to 1 (perhaps that should be true to match the style of other flags) Yes, and debug should be changed from int to bool. Ian
Re: what 68k platform config switch put float return values in fpu register ?
Bernd Roesch wrote: a call of a function and return value with double float is on all m68k-amigaos compiler (that use only other 68k config files but same main source) as this. jsr testfunc move.l d1,-(sp) move.l d0,-(sp) fdmove.d (sp)+,fp1 fsmove.x fp1,fp0 lea (16,sp),sp fjgt L6 You see the func always return the values in Integer Register d0 and d1 put it to stack and then move it from stack to FPU regsiter. m68k-elf use the FPU Register and produce shorter and faster code You cannot change the way doubles are returned for you target! Doing this would render all existing object files useless since the return value is suddenly at a different place. Furthermore you would loose the ability to mix soft-float and hard-float compiled code. Gunther
Re: porting GCC to a micro with a very limited addressing mode --- what to write in LEGITIMATE_ADDRESS, LEGITIMIZE_ADDRESS and micro.md ?!
On 01/25/10 11:21, Sergio Ruocco wrote: Gabriel Paubert wrote: On Mon, Jan 25, 2010 at 01:34:09PM +0100, Sergio Ruocco wrote: Hi everyone, I am porting GCC to a custom 16-bit microcontroller with very limited addressing modes. Basically, it can only load/store using a (general purpose) register as the address, without any offset: LOAD (R2) R1; load R1 from memory at address (R2) STORE R1 (R2) ; store R1 to memory at address (R2) As far as I can understand, this is more limited than the current architectures supported by GCC that I found in the current gcc/config/*. The Itanium (ia64) has the same limited choice of addressing modes. Gabriel Thanks Gabriel. I dived into the ia64 md, but it is still unclear to me how the various parts (macros, define_expand and define_insn in MD etc.) work together to force the computation of a source/dest address plus offset into a register... can anyone help me with this ? GO_IF_LEGITIMATE_ADDRESS is what you need to be looking at. jeff
Re: [gcc] can't build current trunk: ar: .libs/libgomp.lib: File format not recognized
2010/1/25 Joern Rennecke: Quoting Dave Korn dave.korn.cyg...@googlemail.com: On 25/01/2010 14:04, Joern Rennecke wrote: Quoting Christian Joensson christian.joens...@gmail.com: -Xlinker .libs/libgomp-1.dll xgcc: unrecognized option '-pthread' Oops, we can't actually always bootstrap libgomp - we shouldn't try if it's not in target_configdirs. Does the cygwin build work with the attached patch? Was this question and/or patch inspired by the unrecognized option -pthread warning above? Well, I though the reason why you ended up with an unrecognized type libgomp-1.dll was that this diagnostic indicatde a serious problem. Only we've always gotten that on cygwin and it's always been harmless up til now. So how is a build with r156189 different from a build with provious revision? (I'm not up-to-date with head, right now I'm still on r.156105 where the problem apparently arose at r.156189; I'll update to head and get a build going.) I've now committed the patch as r156218, but we'd still like to know if that fixes cygwin builds. FWIW, I still get a problem, this: /bin/sh ./libtool --tag CC --mode=link /usr/local/src/trunk/objdir/./gcc/xgcc -B/usr/local/src/trunk/objdir/./gcc/ -B/usr/local/gnu/i686-pc-cygwin/bin/ -B/usr/local/gnu/i686-pc-cygwin/lib/ -isystem /usr/local/gnu/i686-pc-cygwin/include -isystem /usr/local/gnu/i686-pc-cygwin/sys-include-Wall -Werror -Wc,-pthread -g -O2 -Wl,-O1 -o libgomp.la -version-info 1:0:0 -no-undefined -bindir /usr/local/gnu/bin -rpath /usr/local/gnu/lib/gcc/i686-pc-cygwin/4.5.0 alloc.lo barrier.lo critical.lo env.lo error.lo iter.lo iter_ull.lo loop.lo loop_ull.lo ordered.lo parallel.lo sections.lo single.lo task.lo team.lo work.lo lock.lo mutex.lo proc.lo sem.lo bar.lo ptrlock.lo time.lo fortran.lo affinity.lo libtool: link: /usr/local/src/trunk/objdir/./gcc/xgcc -B/usr/local/src/trunk/objdir/./gcc/ -B/usr/local/gnu/i686-pc-cygwin/bin/ -B/usr/local/gnu/i686-pc-cygwin/lib/ -isystem /usr/local/gnu/i686-pc-cygwin/include -isystem /usr/local/gnu/i686-pc-cygwin/sys-include-shared .libs/alloc.o .libs/barrier.o .libs/critical.o .libs/env.o .libs/error.o .libs/iter.o .libs/iter_ull.o .libs/loop.o .libs/loop_ull.o .libs/ordered.o .libs/parallel.o .libs/sections.o .libs/single.o .libs/task.o .libs/team.o .libs/work.o .libs/lock.o .libs/mutex.o .libs/proc.o .libs/sem.o .libs/bar.o .libs/ptrlock.o .libs/time.o .libs/fortran.o .libs/affinity.o-pthread -Wl,-O1 -o .libs/libgomp-1.dll -Wl,--enable-auto-image-base -Xlinker --out-implib -Xlinker .libs/libgomp-1.dll xgcc: unrecognized option '-pthread' Creating library file: .libs/libgomp-1.dll libtool: link: (cd .libs rm -f libgomp.lib ln -s libgomp-1.dll libgomp.lib) libtool: link: ar rc .libs/libgomp.lib alloc.o barrier.o critical.o env.o error.o iter.o iter_ull.o loop.o loop_ull.o ordered.o parallel.o sections.o single.o task.o team.o work.o lock.o mutex.o proc.o sem.o bar.o ptrlock.o time.o fortran.o affinity.o ar: .libs/libgomp.lib: File format not recognized make[5]: *** [libgomp.la] Error 1 make[5]: Leaving directory `/usr/local/src/trunk/objdir/i686-pc-cygwin/libgomp' make[4]: *** [all-recursive] Error 1 make[4]: Leaving directory `/usr/local/src/trunk/objdir/i686-pc-cygwin/libgomp' make[3]: *** [all] Error 2 make[3]: Leaving directory `/usr/local/src/trunk/objdir/i686-pc-cygwin/libgomp' make[2]: *** [all-stage1-target-libgomp] Error 2 make[2]: Leaving directory `/usr/local/src/trunk/objdir' make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory `/usr/local/src/trunk/objdir' make: *** [all] Error 2 (and, yes, I've been building with libgomp for quite a while on cygwin, and, yes, I do remember the pthread warning showing up before, mentioned it to Dave, and it hadn't caused me problems before to my understanding) -- Cheers, /ChJ
Re: [gcc] can't build current trunk: ar: .libs/libgomp.lib: File format not recognized
Quoting Christian Joensson christian.joens...@gmail.com: FWIW, I still get a problem, this: Could you show the log file from a successful libgomp build with a previous version? Did it usea different ar?
Re: porting GCC to a micro with a very limited addressing mode --- what to write in LEGITIMATE_ADDRESS, LEGITIMIZE_ADDRESS and micro.md ?!
Hi Sergio. My port has similar addressing modes - all memory must be
accessed by one of two registers and can only be accessed indirectly,
indirect with pre increment, and indirect with post increment. The
key is GO_IF_LEGITIMATE_ADDRESS and the legitimate address helper
function. Mine looks like this:
/* Return 1 if the address is OK, otherwise 0.
Used by GO_IF_LEGITIMATE_ADDRESS. */
bool
tomi_legitimate_address (enum machine_mode mode ATTRIBUTE_UNUSED,
rtx x,
bool strict_checking)
{
/* (mem reg) */
if (REG_P (x)
tomi_reg_ok (x, strict_checking)
)
{
return 1;
}
if (GET_CODE(x) == PRE_DEC)
{
...
}
if (GET_CODE(x) == POST_INC)
{
...
}
return 0;
}
tomi_reg_ok returns true if x is any register when strict checking is
clear and true if x is one of my addressing registers when strict
checking is set.
GCC will feed any memory accesses through this function to see if they
are directly supported, and if not it will break them up into
something smaller and try again.
Hope that helps,
-- Michael
2010/1/26 Sergio Ruocco sergio.ruo...@gmail.com:
Gabriel Paubert wrote:
On Mon, Jan 25, 2010 at 01:34:09PM +0100, Sergio Ruocco wrote:
Hi everyone,
I am porting GCC to a custom 16-bit microcontroller with very limited
addressing modes. Basically, it can only load/store using a (general
purpose) register as the address, without any offset:
LOAD (R2) R1 ; load R1 from memory at address (R2)
STORE R1 (R2) ; store R1 to memory at address (R2)
As far as I can understand, this is more limited than the current
architectures supported by GCC that I found in the current gcc/config/*.
The Itanium (ia64) has the same limited choice of addressing modes.
Gabriel
Thanks Gabriel.
I dived into the ia64 md, but it is still unclear to me how the various
parts (macros, define_expand and define_insn in MD etc.) work together
to force the computation of a source/dest address plus offset into a
register... can anyone help me with this ?
Thanks,
Sergio
Re: [gcc] can't build current trunk: ar: .libs/libgomp.lib: File format not recognized
On 25/01/2010 19:31, Joern Rennecke wrote: Quoting Christian Joensson christian.joens...@gmail: FWIW, I still get a problem, this: Could you show the log file from a successful libgomp build with a previous version? Did it usea different ar? It should look something like this: libtool: link: /gnu/gcc/obj-lto/./gcc/xgcc -B/gnu/gcc/obj-lto/./gcc/ -B/opt/gcc-tools/i686-pc-cygwin/bin/ -B/opt/gcc-tools/i686-pc-cygwin/lib/ -isystem /opt/gcc-tools/i686-pc-cygwin/include -isystem /opt/gcc-tools/i686-pc-cygwin/sys-include-shared .libs/alloc.o .libs/barrier.o .libs/critical.o .libs/env.o .libs/error.o .libs/iter.o .libs/iter_ull.o .libs/loop.o .libs/loop_ull.o .libs/ordered.o .libs/parallel.o .libs/sections.o .libs/single.o .libs/task.o .libs/team.o .libs/work.o .libs/lock.o .libs/mutex.o .libs/proc.o .libs/sem.o .libs/bar.o .libs/ptrlock.o .libs/time.o .libs/fortran.o .libs/affinity.o-pthread -Wl,-O1 -o .libs/cyggomp-1.dll -Wl,--enable-auto-image-base -Xlinker --out-implib -Xlinker .libs/libgomp.dll.a xgcc: unrecognized option '-pthread' Creating library file: .libs/libgomp.dll.a libtool: link: ar rc .libs/libgomp.a alloc.o barrier.o critical.o env.o error.o iter.o iter_ull.o loop.o loop_ull.o ordered.o parallel.o sections.o single.o task.o team.o work.o lock.o mutex.o proc.o sem.o bar.o ptrlock.o time.o fortran.o affinity.o libtool: link: ranlib .libs/libgomp.a libtool: link: ( cd .libs rm -f libgomp.la ln -s ../libgomp.la libgomp.la ) Libtool is definitely confused since it's not got the right 'cyg' prefix for the dll in CJ's version, and it's forgotten the .a suffix for the import library, meaning it'll overwrite (or be overwritten by) the DLL. I think we had something like this a while back when gomp was enabled but fortran not configured in. Hang on PR41418. Same symptoms. Haven't verified if there's a similar cause yet, am bootstrapping r156219 ATM. cheers, DaveK
Re: strict aliasing violation
On 25 January 2010 15:51, Piotr Wyderski:
Andrew Haley wrote:
union { float f; uint32 i; } u = {.f = v};
return u.i;
Nope, that is not allowed either.
Of course it is allowed. It's a legitimate gcc extension, and it's
supported by many other compilers too.
It's a C extension, according to the documentation.
In C++ mode (-std=gnu++0x) the compiler does not
understand the u = {.f = v} statement. Is it a feature
or a bug? ;-)
A feature; the C++ committee decided not to support designated initializers.
Re: [gcc] can't build current trunk: ar: .libs/libgomp.lib: File format not recognized
On 25/01/2010 20:19, Dave Korn wrote: am bootstrapping r156219 ATM. Not finished yet, but I may have seen a problem already: make[4]: Leaving directory `/gnu/gcc/obj2/i686-pc-cygwin/libgcc' make[3]: Leaving directory `/gnu/gcc/obj2/i686-pc-cygwin/libgcc' mkdir -p -- i686-pc-cygwin/libgomp Checking multilib configuration for libgomp... Configuring stage 1 in i686-pc-cygwin/libgomp configure: creating cache ./config.cache checking for --enable-version-specific-runtime-libs... yes checking for --enable-generated-files-in-srcdir... no checking build system type... i686-pc-cygwin checking host system type... i686-pc-cygwin checking target system type... i686-pc-cygwin checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /usr/bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for i686-pc-cygwin-gcc... /gnu/gcc/obj2/./gcc/xgcc -B/gnu/gcc/obj2/./gcc/ -B/opt/gcc-tools/i686-pc-cygwin/bin/ -B/opt/gcc-tools/i686-pc-cygwin/lib/ -isystem /opt/gcc-tools/i686-pc-cygwin/include -isystem /opt/gcc-tools/i686-pc-cygwin/sys-include checking for C compiler default output file name... a.exe checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... .exe checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether /gnu/gcc/obj2/./gcc/xgcc -B/gnu/gcc/obj2/./gcc/ -B/opt/gcc-tools/i686-pc-cygwin/bin/ -B/opt/gcc-tools/i686-pc-cygwin/lib/ -isystem /opt/gcc-tools/i686-pc-cygwin/include -isystem /opt/gcc-tools/i686-pc-cygwin/sys-includeaccepts -g... yes checking for /gnu/gcc/obj2/./gcc/xgcc -B/gnu/gcc/obj2/./gcc/ -B/opt/gcc-tools/i686-pc-cygwin/bin/ -B/opt/gcc-tools/i686-pc-cygwin/lib/ -isystem /opt/gcc-tools/i686-pc-cygwin/include -isystem /opt/gcc-tools/i686-pc-cygwin/sys-includeoption to accept ISO C89... none needed checking for style of include used by make... GNU checking dependency style of /gnu/gcc/obj2/./gcc/xgcc -B/gnu/gcc/obj2/./gcc/ -B/opt/gcc-tools/i686-pc-cygwin/bin/ -B/opt/gcc-tools/i686-pc-cygwin/lib/ -isystem /opt/gcc-tools/i686-pc-cygwin/include -isystem /opt/gcc-tools/i686-pc-cygwin/sys-include ... gcc3 checking for i686-pc-cygwin-ar... ar checking for i686-pc-cygwin-ranlib... ranlib checking for perl... /usr/bin/perl checking whether make sets $(MAKE)... (cached) yes checking for makeinfo... makeinfo --split-size=500 --split-size=500 checking for modern makeinfo... yes checking how to print strings... printf checking for a sed that does not truncate output... /usr/bin/sed checking for grep that handles long lines and -e... /usr/bin/grep checking for egrep... /usr/bin/grep -E checking for fgrep... /usr/bin/grep -F checking for ld used by /gnu/gcc/obj2/./gcc/xgcc -B/gnu/gcc/obj2/./gcc/ -B/opt/gcc-tools/i686-pc-cygwin/bin/ -B/opt/gcc-tools/i686-pc-cygwin/lib/ -isystem /opt/gcc-tools/i686-pc-cygwin/include -isystem /opt/gcc-tools/i686-pc-cygwin/sys-include ... /gnu/gcc/obj2/./gcc/collect-ld checking if the linker (/gnu/gcc/obj2/./gcc/collect-ld) is GNU ld... yes checking for BSD- or MS-compatible name lister (nm)... /gnu/gcc/obj2/./gcc/nm checking the name lister (/gnu/gcc/obj2/./gcc/nm) interface... BSD nm checking whether ln -s works... yes checking the maximum length of command line arguments... 8192 checking whether the shell understands some XSI constructs... yes checking whether the shell understands +=... yes checking for /gnu/gcc/obj2/./gcc/collect-ld option to reload object files... -r checking for i686-pc-cygwin-objdump... objdump checking how to recognize dependent libraries... file_magic ^x86 archive import|^x86 DLL checking for i686-pc-cygwin-ar... (cached) ar checking for i686-pc-cygwin-strip... strip checking for i686-pc-cygwin-ranlib... (cached) ranlib checking command to parse /gnu/gcc/obj2/./gcc/nm output from /gnu/gcc/obj2/./gcc/xgcc -B/gnu/gcc/obj2/./gcc/ -B/opt/gcc-tools/i686-pc-cygwin/bin/ -B/opt/gcc-tools/i686-pc-cygwin/lib/ -isystem /opt/gcc-tools/i686-pc-cygwin/include -isystem /opt/gcc-tools/i686-pc-cygwin/sys-includeobject... ok checking how to run the C preprocessor... /gnu/gcc/obj2/./gcc/xgcc -B/gnu/gcc/obj2/./gcc/ -B/opt/gcc-tools/i686-pc-cygwin/bin/ -B/opt/gcc-tools/i686-pc-cygwin/lib/ -isystem /opt/gcc-tools/i686-pc-cygwin/include -isystem /opt/gcc-tools/i686-pc-cygwin/sys-include-E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking for dlfcn.h... yes checking for objdir... .libs checking if /gnu/gcc/obj2/./gcc/xgcc -B/gnu/gcc/obj2/./gcc/ -B/opt/gcc-tools/i686-pc-cygwin/bin/ -B/opt/gcc-tools/i686-pc-cygwin/lib/ -isystem
Re: [gcc] can't build current trunk: ar: .libs/libgomp.lib: File format not recognized
This probably is a new version of PR41418 then. We have the problem that fortran is turned on in --enable-languages, so libgomp configure expects the fortran compiler to be available. Does this fix it for you? Index: configure.ac === --- configure.ac(revision 155240) +++ configure.ac(working copy) @@ -146,7 +146,11 @@ case `echo $GFORTRAN` in -* | no* ) FC=no ;; *) -FC=$GFORTRAN ;; +if test -x $GFORTRAN; then + FC=$GFORTRAN +else + FC=no +fi ;; esac AC_PROG_FC(gfortran) FCFLAGS=$FCFLAGS -Wall (untested) Paolo
Re: [gcc] can't build current trunk: ar: .libs/libgomp.lib: File format not recognized
On 25/01/2010 20:58, Paolo Bonzini wrote: This probably is a new version of PR41418 then. We have the problem that fortran is turned on in --enable-languages, so libgomp configure expects the fortran compiler to be available. Does this fix it for you? That succeeded for rm -rf i686-pc-cygwin/libgomp; make configure-target-libgomp all-target-libgomp. I'll leave a full bootstrap running overnight but it looks sound to me. cheers, DaveK
Re: fixincludes
Basile STARYNKEVITCH bas...@starynkevitch.net writes: Why is it still useful on recent GNU/Linux systems? In general, it's not. But future versions of gcc may want changes to current versions of glibc. We've seen that happen in the past, and it is likely to happen again in the future. (E.g., we needed to use fixincludes when we flipped the meaning of extern inline from the GNU89 meaning to the C99 meaning when running in C99 mode.) Ian
Re: Successful make profiledbootstrap of GCC 4.4.3 and GCC 4.5.0 (SVN revision 156177) on Snow Leopard 10.6.2 x86_64-apple-darwin10.2.0
On Sun, Jan 24, 2010 at 08:26:04PM -0500, Olexa Bilaniuk wrote: I am on Mac OS X Snow Leopard. There has been some noise around the forums that GCC fails for various reasons. It turns out that despite having all the requirements to run 64-bit systems, including a 64-bit processor (an Intel Core 2 Duo), no Macs boot the 64-bit kernel by default and only 4 (These being Mac Pros, Xserves, Macbook Pros and iMacs) are allowed to boot i...@all, leaving that the system kernel runs 32-bit, but almost every application is 64-bit. Also, the command uname returns i386 despite the Core 2 Duo being more of a i686 or x86_64, a 64-bit processor. It seems therefore that config.guess confuses itself in bitness, picking the 32-bit version called i386 rather than the correct choice, x86_64. So the recommendation is to add an entry under Build Stats saying that 4.4.3 under x86_64-apple-darwin10.2.0 is successful, and to add to the system-specific installation notes to add these options to the configure: --host=x86_64-apple-darwin10 --target=x86_64-apple-darwin10 --host=x86_64-apple-darwin10 This issue doesn't exist in either gcc 4.4.3 or gcc trunk as both contain the updated config.guess which properly detects the code generation of the default system compiler rather than using uname for obtaining the architecture. Thus on a EMT64 compatible processor config.guess will return... x86_64-apple-darwin10.2.0 for the default compiler but if you set CC to gcc-4.0, it will return... i386-apple-darwin10.2.0 Jack
Re: [gcc] can't build current trunk: ar: .libs/libgomp.lib: File format not recognized
On 25/01/2010 22:38, Dave Korn wrote: On 25/01/2010 20:58, Paolo Bonzini wrote: Does this fix it for you? That succeeded for rm -rf i686-pc-cygwin/libgomp; make configure-target-libgomp all-target-libgomp. I'll leave a full bootstrap running overnight That completed fine. cheers, DaveK
Re: can't build current trunk: ar: .libs/libgomp.lib: File format not recognized
On 01/25/2010 11:38 PM, Dave Korn wrote: On 25/01/2010 20:58, Paolo Bonzini wrote: This probably is a new version of PR41418 then. We have the problem that fortran is turned on in --enable-languages, so libgomp configure expects the fortran compiler to be available. Does this fix it for you? That succeeded for rm -rf i686-pc-cygwin/libgomp; make configure-target-libgomp all-target-libgomp. I'll leave a full bootstrap running overnight but it looks sound to me. Committed, I think we can revert Joern's second patch, I'll check in the next 1-2 days. Paolo
[Bug debug/37022] internal compiler error: in compute_barrier_args_size
--- Comment #18 from jakub at gcc dot gnu dot org 2010-01-25 08:22 --- It is no longer marged regression, so no longer release critical. Anyway, the goal should be to reenable the asserts in dwarf2out.c and fix the issues, because they really result in wrong unwind info. Only the unwinder uses it though (DW_CFA_GNU_args_size), so the question is if we can come up with a testcase that actually misbehaves of it. There are two known cases which triggered the assertions - one is alloca with an argument that ends up to be constant in the end, and the other is crossjumping of noreturn sequences with different stack push depth. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Severity|blocker |major Priority|P1 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37022
[Bug c++/42824] c++ compilation complains about error: call of overloaded
--- Comment #8 from mario-baumann at web dot de 2010-01-25 08:24 --- Hi Jonathan, thanks for the hint! I attached a version (goo.cpp) without boost. g++ -c goo.cpp goo.cpp: In member function 'void EvalT::eval(int_0) [with int V = 0, T = Mtrl]': goo.cpp:42:9: instantiated from 'void EvalT::eval() [with int V = 0, T = Mtrl]' goo.cpp:65:20: instantiated from here goo.cpp:57:9: error: call of overloaded 'value(EvalMtrl::WrapQuan0 )' is ambiguous goo.cpp:49:10: note: candidates are: void EvalT::value(EvalT::WrapQuanV2 ) [with int V = 0, int V2 = 0, T = Mtrl] goo.cpp:52:10: note: void EvalT::value(EvalT::WrapQuan0 ) [with int V = 0, T = Mtrl] -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42824
[Bug c++/42824] c++ compilation complains about error: call of overloaded
--- Comment #9 from mario-baumann at web dot de 2010-01-25 08:26 --- Created an attachment (id=19702) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19702action=view) new c++ source file (independent of boost) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42824
[Bug fortran/42848] compiler crashes and asks for this bug report
--- Comment #4 from burnus at gcc dot gnu dot org 2010-01-25 08:30 --- (In reply to comment #3) Today I am not able to reproduce the error. The compiler is working. Where exactly does the file m.mod reside? In the user directory or in a compiler directory? By default in the current directory - unless you used the option -Jdirectory to specify a different one. Note: In order to help writing makefiles which have dependencies on the .mod files, gfortran only overwrites the .mod files if they have changed. Thus, to reproduce the problem, you could compile the program with a different compiler or an older version of GCC - or simply create in any editor the .mod file. (Modifying the Fortran module + running gfortran also produces a new .mod file, but I think works also without the patch of PR 40195.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42848
[Bug fortran/42848] compiler crashes and asks for this bug report
--- Comment #5 from frank dot braun at rz dot uni-regensburg dot de 2010-01-25 08:36 --- 've got it. Modifying the .mod file by hand makes the compiler crash. Deleting it lets it work correctly. The compiler shouldn't crash anyway. But with a new version this problem should be solved too, isn't it? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42848
[Bug libgcj/40860] [4.4/4.5 regression] regressions in libjava testsuite on arm-linux
--- Comment #2 from mikpe at it dot uu dot se 2010-01-25 09:33 --- I had very recently updated binutils from 2.19.1 to 2.20 + branch updates + some fixes from trunk. Going back to binutils 2.19.1 while changing nothing else eliminated the StackTrace2 and Throw_3 failures from gcc-4.3. My last gcc-4.4 build and test suite run was probably still with binutils-2.19.1, which might explain why I didn't see those errors there. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40860
[Bug fortran/42858] [4.5 Regression] ICE in gfc_array_dimen_size at ../../trunk/gcc/fortran/array.c:2063
--- Comment #4 from burnus at gcc dot gnu dot org 2010-01-25 09:37 ---
(In reply to comment #3)
This appears to fix this: regression tested on x86-64
I think the following patch is better. My intrinsic check was bogus.
Index: array.c
===
--- array.c (revision 156196)
+++ array.c (working copy)
@@ -2054,7 +2054,7 @@ gfc_array_dimen_size (gfc_expr *array, i
}
if (array-symtree-n.sym-attr.generic
- !array-symtree-n.sym-attr.intrinsic)
+ array-value.function.esym != NULL)
{
if (spec_dimen_size (array-value.function.esym-as, dimen, result)
== FAILURE)
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |burnus at gcc dot gnu dot
|dot org |org
Status|NEW |ASSIGNED
Last reconfirmed|2010-01-25 01:18:04 |2010-01-25 09:37:46
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42858
[Bug middle-end/42859] [4.5 regression] ICE in verify_flow_info
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-01-25 09:56 --- Confirmed. Reducing. -- 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 |2010-01-25 09:56:22 date|| Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42859
[Bug middle-end/42859] [4.5 regression] ICE in verify_flow_info
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-01-25 10:06 ---
I suppose this is from rths exception rewrite.
void start (void);
void ptw32_terminate (void)
{
try {
start ();
}
catch( int ) { }
catch( int ) { }
}
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||rth at gcc dot gnu dot org
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42859
[Bug libstdc++/42832] Revisit std::function for aliasing issues
--- Comment #5 from paolo dot carlini at oracle dot com 2010-01-25 10:10 --- Ok, I see that asking was a good idea, the tangle of issues is quite complex. Anyway, this is my current proposal: let' use for now your mildly optimized and in any case correct solution using a loop of char-wise std::swap, the first solution you proposed on the gcc-patches discussion. For both std and tr1. Likely tr1 will stay like that forever. Let's remove the dependency of this bug on the overzealous memcpy optimization bug and the blocking of the optimization issue which started this discussion; let's add instead dependency on the uninitialized_swap enhancement. Let's keep the present bug open of course, as enhancement. Are you willing to prepare a patch including a comment, better two different comments one simpler for the tr1 version and one slightly longer for the std version? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42832
[Bug fortran/42852] gfortran -Wall warns about truncated lines when only a continuation character is truncated
--- Comment #4 from bugs at 59A2 dot org 2010-01-25 10:33 --- (In reply to comment #3) So it's gfortran's fault you write non-portable code, and instead of dealing with it on your end, you think that gfortran developers should do the work to make your code compile. Actually, gfortran versions up to and including 4.4.2 do not complain about this usage (but it looks like that was due to -Wline-truncation being defective). All versions of gfortran compile this hybrid source correctly, it's only (what I consider) a spurious warning with -Wline-truncation, and only in the 4.5 snapshot. I'll note that I stated that I felt it should be closed with a WONTFIX, but changed it to an enhancement request. In lieu of receiving a patch from you to address the issue, someone may someday in the distant future, when there are less important bugs to fix, might address the issue. I'm not familiar with the project, but if you tell me where to look, I may be able to submit a patch. The Note in the Standard is assuming a specific behavior for a processor-dependent behavior. gfortran currently does not assume that specific choice. Based on the way the source is compiled, as opposed to warnings under -Wline-truncation, gfortran *does* make that specific choice. If you are saying that this may change in the future (making such source an error instead of a warning), then the warning is completely valid (but anticipate user complaints if such a change happens). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42852
[Bug tree-optimization/42585] [4.5 Regression] SRA is not good for structure copies with one replacement any more
--- Comment #7 from jamborm at gcc dot gnu dot org 2010-01-25 10:38 --- I understand that the bootstrap problem is PR 42836 and is now fixed (thanks for that). SRA now removes the structures in the testcase from bug description and so I consider this to be fixed. -- jamborm at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42585
[Bug debug/42861] New: [4.4/4.5 Regression] Spill slots not tracked during var-tracking
PR37815 introduced a regression - no decls are tracked in spill slots, as they have MEM_EXPR set to get_spill_slot_decl (false) instead of the real decl. On the testcase I'm going to attach, the tok argument is (and clearly has to be) live through the whole function except maybe last few instructions in epilogue, but as gcc decides to use regparm(2) calling convention, var-tracking thinks the parameter isn't live in most of the function. I'm afraid we'll need to track what values live in the spill slots during var-tracking. Easy hack to get at least something working would be just to handle spill slots that have at most one decl stored to it - then just one vector mapping byte offsets in the spill area to decls or REG_EXPRs would be sufficient. We'd just walk the whole function, note what is stored into the spill slots and if there are any conflicts, just remember that we can't use it. Or we could actually track what is currently stored in each spill slot even if the slot isn't for the same decl in all places. -- Summary: [4.4/4.5 Regression] Spill slots not tracked during var- tracking Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jakub at gcc dot gnu dot org GCC target triplet: i686-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42861
[Bug debug/42861] [4.4/4.5 Regression] Spill slots not tracked during var-tracking
--- Comment #1 from jakub at gcc dot gnu dot org 2010-01-25 11:45 --- Created an attachment (id=19703) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19703action=view) parsetok.c.bz2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42861
[Bug testsuite/42854] [4.4/4.5 Regression] FAIL: gcc.dg/darwin-weakimport-[13].c scan-assembler-not *
--- Comment #1 from jakub at gcc dot gnu dot org 2010-01-25 12:03 --- This is completely undocumented attribute, so you first need to get Apple to actually document what it does and get the documentation into doc/extend.texi. Especially nothing explains the relationship between weak attribute, weak_import attribute and #pragma weak. Unless this is clarified, there is nothing that can be done about this, complain to Apple. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42854
[Bug debug/42861] [4.4/4.5 Regression] Spill slots not tracked during var-tracking
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42861
[Bug target/38697] gcc.target/arm/neon/neon.exp tests for vmov fail on arm-linux-eabi
--- Comment #9 from ramana at gcc dot gnu dot org 2010-01-25 12:29 ---
Subject: Bug 38697
Author: ramana
Date: Mon Jan 25 12:29:25 2010
New Revision: 156206
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156206
Log:
Backport target/38697
Backport from trunk.
2010-01-19 Ramana Radhakrishnan ramana.radhakrish...@arm.com
PR target/38697
* config/arm/neon-testgen.m (emit_automatics): New parameter
features. Adjust for Fixed_return_reg feature.
(test_intrinsic): Call emit_automatics with new feature.
* config/arm/neon.ml: Update copyright years.
(features): New Fixed_return_reg feature.
(ops): Update feature for Vget_low.
Backport from mainline.
2010-01-19 Ramana Radhakrishnan ramana.radhakrish...@arm.com
PR target/38697.
* gcc.target/arm/neon/vget_lowf32.c: Regenerate.
* gcc.target/arm/neon/vget_lowp16.c: Likewise.
* gcc.target/arm/neon/vget_lowp8.c: Likewise.
* gcc.target/arm/neon/vget_lows16.c: Likewise.
* gcc.target/arm/neon/vget_lows32.c: Likewise.
* gcc.target/arm/neon/vget_lows64.c: Likewise.
* gcc.target/arm/neon/vget_lows8.c: Likewise.
* gcc.target/arm/neon/vget_lowu16.c: Likewise.
* gcc.target/arm/neon/vget_lowu32.c: Likewise.
* gcc.target/arm/neon/vget_lowu64.c: Likewise.
* gcc.target/arm/neon/vget_lowu8.c: Likewise.
Modified:
branches/gcc-4_4-branch/ (props changed)
branches/gcc-4_4-branch/gcc/ChangeLog
branches/gcc-4_4-branch/gcc/config/arm/neon-testgen.ml
branches/gcc-4_4-branch/gcc/config/arm/neon.ml
branches/gcc-4_4-branch/gcc/testsuite/ChangeLog
branches/gcc-4_4-branch/gcc/testsuite/gcc.target/arm/neon/vget_lowf32.c
branches/gcc-4_4-branch/gcc/testsuite/gcc.target/arm/neon/vget_lowp16.c
branches/gcc-4_4-branch/gcc/testsuite/gcc.target/arm/neon/vget_lowp8.c
branches/gcc-4_4-branch/gcc/testsuite/gcc.target/arm/neon/vget_lows16.c
branches/gcc-4_4-branch/gcc/testsuite/gcc.target/arm/neon/vget_lows32.c
branches/gcc-4_4-branch/gcc/testsuite/gcc.target/arm/neon/vget_lows64.c
branches/gcc-4_4-branch/gcc/testsuite/gcc.target/arm/neon/vget_lows8.c
branches/gcc-4_4-branch/gcc/testsuite/gcc.target/arm/neon/vget_lowu16.c
branches/gcc-4_4-branch/gcc/testsuite/gcc.target/arm/neon/vget_lowu32.c
branches/gcc-4_4-branch/gcc/testsuite/gcc.target/arm/neon/vget_lowu64.c
branches/gcc-4_4-branch/gcc/testsuite/gcc.target/arm/neon/vget_lowu8.c
Propchange: branches/gcc-4_4-branch/
('svn:mergeinfo' added)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38697
[Bug target/38697] gcc.target/arm/neon/neon.exp tests for vmov fail on arm-linux-eabi
--- Comment #10 from ramana at gcc dot gnu dot org 2010-01-25 12:30 --- Fixed on branch . -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.4.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38697
[Bug testsuite/42854] [4.4/4.5 Regression] FAIL: gcc.dg/darwin-weakimport-[13].c scan-assembler-not *
--- Comment #2 from dominiq at lps dot ens dot fr 2010-01-25 12:53 --- This is completely undocumented attribute ... What is the undocumented attribute? If you mean -fno-asynchronous-unwind-tables, you don't need it for the tests to fail. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42854
[Bug testsuite/42854] [4.4/4.5 Regression] FAIL: gcc.dg/darwin-weakimport-[13].c scan-assembler-not *
--- Comment #3 from jakub at gcc dot gnu dot org 2010-01-25 12:59 --- I mean that grep weak_import doc/* yields nothing at all (and google for weak_import doesn't show up any useful documentation either). It seems that Geoff Keating's implementation of the attribute (how could it be committed without documentation nor at least some words on what it is meant to do?) basically ignored it if weak attribute was also specified. Just removing those lookup_attribute (, weak) tests would cure this. That really depends on what __attribute__((weak, weak_import)) is supposed to mean (if anything). Or what means combination of #pragma weak and weak_import attribute for the same decl name. Also, what matters is if undefined weak_import symbols are supposed to generate weak directives or not. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42854
[Bug testsuite/41522] gcc.c-torture/compile/pr38789.c fails on Solaris/SPARC with native assembler
--- Comment #2 from ro at gcc dot gnu dot org 2010-01-25 14:54 --- Subject: Bug 41522 Author: ro Date: Mon Jan 25 14:54:15 2010 New Revision: 156213 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156213 Log: PR testsuite/41522 * gcc.c-torture/compile/pr38789.c: Change to dg-do compile. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.c-torture/compile/pr38789.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41522
[Bug testsuite/41522] gcc.c-torture/compile/pr38789.c fails on Solaris/SPARC with native assembler
--- Comment #3 from ro at gcc dot gnu dot org 2010-01-25 14:55 --- Mine. -- ro at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ro at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-01-25 14:55:01 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41522
[Bug testsuite/41522] gcc.c-torture/compile/pr38789.c fails on Solaris/SPARC with native assembler
--- Comment #4 from ro at gcc dot gnu dot org 2010-01-25 14:56 --- Fixed for 4.5.0: http://gcc.gnu.org/ml/gcc-patches/2010-01/msg01255.html -- ro at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41522
[Bug fortran/42858] [4.5 Regression] ICE in gfc_array_dimen_size at ../../trunk/gcc/fortran/array.c:2063
--- Comment #5 from burnus at gcc dot gnu dot org 2010-01-25 16:22 --- Subject: Bug 42858 Author: burnus Date: Mon Jan 25 16:21:42 2010 New Revision: 156214 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156214 Log: 2010-01-25 Tobias Burnus bur...@net-b.de PR fortran/42858 * array.c (gfc_array_dimen_size): Fix intrinsic procedure check. 2010-01-25 Tobias Burnus bur...@net-b.de PR fortran/42858 * gfortran.dg/generic_21.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/generic_21.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/array.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42858
[Bug fortran/42858] [4.5 Regression] ICE in gfc_array_dimen_size at ../../trunk/gcc/fortran/array.c:2063
--- Comment #6 from burnus at gcc dot gnu dot org 2010-01-25 16:24 --- And FIXED. Thanks a lot for the report and sorry for breaking the code! -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Keywords||ice-on-valid-code Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42858
[Bug libstdc++/42832] Revisit std::function for aliasing issues
--- Comment #6 from rguenther at suse dot de 2010-01-25 16:29 --- Subject: Re: Revisit std::function for aliasing issues On Mon, 25 Jan 2010, paolo dot carlini at oracle dot com wrote: --- Comment #5 from paolo dot carlini at oracle dot com 2010-01-25 10:10 --- Ok, I see that asking was a good idea, the tangle of issues is quite complex. Anyway, this is my current proposal: let' use for now your mildly optimized and in any case correct solution using a loop of char-wise std::swap, the first solution you proposed on the gcc-patches discussion. For both std and tr1. Likely tr1 will stay like that forever. Let's remove the dependency of this bug on the overzealous memcpy optimization bug and the blocking of the optimization issue which started this discussion; let's add instead dependency on the uninitialized_swap enhancement. Let's keep the present bug open of course, as enhancement. Are you willing to prepare a patch including a comment, better two different comments one simpler for the tr1 version and one slightly longer for the std version? I'll let the dust settle a bit on the gcc-patches discussion; I can then post a patch along the above lines. Thanks, Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42832
[Bug tree-optimization/42771] [4.5 Regression] ICE: in graphite_loop_normal_form, at graphite-sese-to-poly.c (2)
--- Comment #4 from uramakrishna at gmail dot com 2010-01-25 16:30 --- Created an attachment (id=19704) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19704action=view) A further reduced case to show the ICE Unable to find non-zero value for 'known_niter'. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42771
[Bug c++/42862] New: Anonymous Structures: Incorrect DWARF data generated
GCC Version: 3.4.4 and 4.1.2
The GNU 4.1.2 C++ compiler is not generating the proper typedef DIEs in the
DWARF data.
For example, the type definition BASE_UNION is defined as
typedef union
{
char ch;
int iVal;
long IVal;
} BASE_UNION;
The GNU 4.1.2 compiler generates the following DWARF data for this type
11279: Abbrev Number: 35 (DW_TAG_union_type)
127a DW_AT_sibling : 12a8
127e DW_AT_name: $_4
1282 DW_AT_byte_size : 4
1283 DW_AT_decl_file : 35
1284 DW_AT_decl_line : 29
21285: Abbrev Number: 36 (DW_TAG_member)
1286 DW_AT_name: ch
1289 DW_AT_decl_file : 35
128a DW_AT_decl_line : 30
128b DW_AT_type: c0d
2128f: Abbrev Number: 36 (DW_TAG_member)
1290 DW_AT_name: iVal
1295 DW_AT_decl_file : 35
1296 DW_AT_decl_line : 31
1297 DW_AT_type: b7f
2129b: Abbrev Number: 36 (DW_TAG_member)
129c DW_AT_name: IVal
12a1 DW_AT_decl_file : 35
12a2 DW_AT_decl_line : 32
12a3 DW_AT_type: b86
Notice that the union name has been set to $_4 in DIE 1279. The correct
DWARF data would have no name attribute for the union DIE 1279 and it would
have a type-def DIE which pointed to the union die such as:
1: DW_TAG_typedef
DW_AT_name: BASE_UNION
DW_AT_decl_line : 26
DW_AT_decl_column : 3
DW_AT_decl_file : 9
DW_AT_type: 0x1279
Interestingly enough, the GNU 3.4.4 compiler generates the following DWARF data
from the same source code and this is also incomplete:
111d0: Abbrev Number: 27 (DW_TAG_union_type)
DW_AT_sibling : 123f
DW_AT_name: (indirect string, offset: 0x6e): BASE_UNION
DW_AT_byte_size : 4
DW_AT_decl_file : 3
DW_AT_decl_line : 29
--
Summary: Anonymous Structures: Incorrect DWARF data generated
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: louzonr at yahoo dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42862
[Bug tree-optimization/42771] [4.5 Regression] ICE: in graphite_loop_normal_form, at graphite-sese-to-poly.c (2)
--- Comment #5 from amonakov at gcc dot gnu dot org 2010-01-25 17:06
---
We fail to find number of iterations after rewriting reductions out of SSA.
Before graphite pass, IR looks like (for the previous testcase, pr42771.c):
bb 9:
# j_26 = PHI j_20(10)
bb 10:
# j_33 = PHI j_26(9), 1(16)
D.2747_16 = B[j_33][0];
D.2748_17 = j_33 + -1;
D.2749_18 = B[D.2748_17][0];
D.2750_19 = D.2749_18 ^ D.2747_16;
B[j_33][0] = D.2750_19;
j_20 = j_33 + 1;
if (jm_14(D) j_20)
goto bb 9;
else
goto bb 11;
At the time of the ICE, IR is transformed to
(gdb) call debug_loop(use_loop, 3)
loop_3 (header = 10, latch = 9, niter = (unsigned int) jm_14(D) + 4294967294,
upper_bound = 2147483646)
{
bb_9 (preds = {bb_10 }, succs = {bb_10 })
{
bb 9:
# .MEM_24 = PHI .MEM_78(10)
# VUSE .MEM_24
j_26 = Close_Phi.13[0];
# .MEM_79 = VDEF .MEM_24
General_Reduction.14[0] = j_26;
}
bb_10 (preds = {bb_9 bb_16 }, succs = {bb_9 bb_11 })
{
bb 10:
# .MEM_15 = PHI .MEM_79(9), .MEM_77(16)
# VUSE .MEM_15
D.2766_76 = General_Reduction.14[0];
j_33 = D.2766_76;
# VUSE .MEM_15
D.2747_16 = B[j_33][0];
D.2748_17 = j_33 + -1;
# VUSE .MEM_15
D.2749_18 = B[D.2748_17][0];
D.2750_19 = D.2749_18 ^ D.2747_16;
# .MEM_30 = VDEF .MEM_15
B[j_33][0] = D.2750_19;
j_20 = j_33 + 1;
# .MEM_78 = VDEF .MEM_30
Close_Phi.13[0] = j_20;
if (jm_14(D) j_20)
goto bb 9;
else
goto bb 11;
}
}
We would fail to discover scalar evolution of j_33.
--
amonakov at gcc dot gnu dot org changed:
What|Removed |Added
CC||amonakov at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42771
[Bug tree-optimization/42806] -fcompare-debug failure (length) at -O1 in recent builds
--- Comment #2 from zsojka at seznam dot cz 2010-01-25 17:34 --- Since: r155937 | rguenth | 2010-01-15 12:53:26 +0100 (Fri, 15 Jan 2010) | 10 lines 2010-01-15 Richard Guenther rguent...@suse.de PR middle-end/42739 * tree-cfgcleanup.c (remove_forwarder_block): Move destination labels of computed or non-local gotos to the destination. * tree-cfg.c (gimple_verify_flow_info): Verify that a EH landing pad label is the first label. * g++.dg/torture/pr42739.C: New testcase. -- zsojka at seznam dot cz changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42806
[Bug libstdc++/42832] Revisit std::function for aliasing issues
--- Comment #7 from paolo dot carlini at oracle dot com 2010-01-25 17:36 --- Ageeed. Indeed, I see there is a discussion ongoing. In the present time frame let's figure out something minimally invasive, decently (if not perfectly) optimized, and minimally coupled one way or the other to the other open issues. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42832
[Bug c++/42748] warnings about 'mangling of 'va_list' has changed in GCC 4.4' not suppressed in sytem headers
-- paolo dot carlini at oracle dot com changed: What|Removed |Added Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42748
[Bug tree-optimization/42586] load-modify-store on x86 should be a single instruction
--- Comment #20 from jamborm at gcc dot gnu dot org 2010-01-25 17:51 --- (In reply to comment #6) I think if we get the old SRA behavior back for this code, we will get this optimization in 4.5 since we remove the sptr-base and the other unnecessary store during PRE. We now should have the old SRA behavior back (this was PR 42585). I have checked only very briefly but I believe that this testcase is now compiled as requested in the bug summary. I'd be grateful if someone could double-check this and close this bug if it is indeed so. Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42586
[Bug libstdc++/36101] deps on other host libraries incorrect
--- Comment #29 from amylaar at gcc dot gnu dot org 2010-01-25 18:01 --- Subject: Bug 36101 Author: amylaar Date: Mon Jan 25 18:01:29 2010 New Revision: 156218 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156218 Log: PR libstdc++/36101, PR libstdc++/42813 * configure.ac (bootstrap_target_libs): Make inclusion of target-libgomp conditional on libgomb being in target_configdirs. * configure: Regenerate. Modified: trunk/ChangeLog trunk/configure trunk/configure.ac -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36101
[Bug libstdc++/42813] --enable-build-with-cxx libstdc++-v3 is incomplete
--- Comment #8 from amylaar at gcc dot gnu dot org 2010-01-25 18:01 --- Subject: Bug 42813 Author: amylaar Date: Mon Jan 25 18:01:29 2010 New Revision: 156218 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156218 Log: PR libstdc++/36101, PR libstdc++/42813 * configure.ac (bootstrap_target_libs): Make inclusion of target-libgomp conditional on libgomb being in target_configdirs. * configure: Regenerate. Modified: trunk/ChangeLog trunk/configure trunk/configure.ac -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42813
[Bug middle-end/42590] unnecessary stack frame set up
--- Comment #1 from jamborm at gcc dot gnu dot org 2010-01-25 18:02 --- Since PR 42585 is fixed, the optimized dump (at -O2) is bb 2: _T2$curr_12 = sptr_1(D)-curr; D.1966_7 = _T2$curr_12 + -1; sptr_1(D)-curr = D.1966_7; return 0; } The generated assembly is: Cyc_string_ungetc: pushl %ebp movl%esp, %ebp movl12(%ebp), %eax subl$1, (%eax) xorl%eax, %eax popl%ebp ret With -O2 -fomit-frame-pointer it is: Cyc_string_ungetc: movl8(%esp), %eax subl$1, (%eax) xorl%eax, %eax ret (Which is weird because the manual says that -fomit-frame-pointer is enabled at -O2 by default - maybe this is the actual bug here now?) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42590
[Bug middle-end/42590] unnecessary stack frame set up
--- Comment #2 from jakub at gcc dot gnu dot org 2010-01-25 18:24 --- On i?86-linux -fomit-frame-pointer is not the default, on the contrary. info gcc says: `-O' also turns on `-fomit-frame-pointer' on machines where doing so does not interfere with debugging. and i?86-linux is not considered such machine (unlike e.g. x86_64-linux). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42590
[Bug middle-end/42590] unnecessary stack frame set up
--- Comment #3 from jamborm at gcc dot gnu dot org 2010-01-25 18:30 --- I have found the sentence you quoted in the manual too but it refers only to -O1 (as far as I understand it). And the description of -fomit-frame-pointer simply states that Enabled at levels -O, -O2, -O3, -Os. So I'd say that at least the documentation is slightly confusing. Anyway, does this mean that this issue is also resolved now? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42590
[Bug c++/42824] c++ compilation complains about error: call of overloaded
--- Comment #10 from bangerth at gmail dot com 2010-01-25 18:39 --- This works with gcc 4.3 and 4.4 I don't have mainline lying around here but if it really fails there it would be a 4.5 regression which should get it P1 status. Can someone try? W. -- bangerth at gmail dot com changed: What|Removed |Added CC||bangerth at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42824
[Bug c++/42768] ICE: libstdc++-v3/libsupc++/vec.cc:354
--- Comment #3 from bangerth at gmail dot com 2010-01-25 18:42 --- Someone on a win64 machine may have to check this. W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42768
[Bug middle-end/42863] New: [4.5] Regression whith auto increments
This is a general m68k code generation regression. Starting with revision
150588 GCC for m68k generates surprising code for auto increments, eg.
for a strlcpy implementation. Compiling this code with the 4.5.0 snapshot
from 20100107 yields:
-- 4.5.0 --
_strlcpy:
movel d3,s...@-
movel d2,s...@-
movel sp@(16),d0
movel sp@(20),d1
jeq L7
movel d0,a0
movel sp@(12),a1
L3:
movel a0,d2
subql #1,d1
jeq L11
moveb a...@+,d2
moveb d2,a...@+
movel a0,d3 | --
tstb d2 | --
jne L3
L4:
subl d3,d0
notl d0
movel s...@+,d2
movel s...@+,d3
rts
L7:
movel d0,d2
movel d2,a0
L6:
moveb a...@+,d1
movel a0,d3 | --
tstb d1 | --
jeq L4
moveb a...@+,d1
movel a0,d3 | --
tstb d1 | --
jne L6
jra L4
L11:
clrb a1@
movel d2,a0
jra L6
-- cut --
Suddenly GCC inserts useless moves and because of these moves has also
to generate explicit tst instructions. Older GCC versions generated better
code by using tst.b incrementing an address register without extra move
instructions, i.e. 4.4.0:
-- 4.4.0 (release) --
_strlcpy:
movel d2,s...@-
movel sp@(8),a1
movel sp@(12),d0
movel sp@(16),d1
jne L2
movel d0,a0
L8:
tstb a...@+
jne L8
L5:
subl a0,d0
notl d0
movel s...@+,d2
rts
L2:
movel d0,a0
subql #1,d1
jeq L11
L6:
moveb a...@+,d2
moveb d2,a1@
jeq L5
addql #1,a1
subql #1,d1
jne L6
L11:
clrb a1@
tstb a...@+
jne L8
jra L5
-- cut --
Environment:
System: FreeBSD 6.3-STABLE #0: Sat Mar 1 11:12:32 CET 2008
r...@sirius:/usr/obj/usr/src/sys/SIRIUS i386
host: i386-unknown-freebsd6.3
build: i386-unknown-freebsd6.3
target: m68k-unknown-amigaos
configured with: ../gcc-4.5-gg/configure --disable-nls --disable-libssp
--enable-languages=c --with-gmp=/usr/local --disable-tls --target=m68k-amigaos
How-To-Repeat:
Compiling the following code with
gcc-4.5.0 -O2 -fomit-frame-pointer strlcpy.c -o -
demonstrates the problem. FWIW, m68k-elf exhibits the very same problem!
-- cut --
typedef unsigned long size_t;
size_t
strlcpy(char *dst, const char *src, size_t n)
{ const char *s = src;
if (n) {
while (--n)
if ((*dst++ = *s++) == '\0')
goto out;
*dst = '\0';
}
while (*s++ != '\0')
continue;
out:
return ~(src - s);
}
-- cut --
--- Comment #1 from gnikl at users dot sourceforge dot net 2010-01-25
19:34 ---
Fix:
Reverting rev 150588 restores the previous behaviour.
--
Summary: [4.5] Regression whith auto increments
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gnikl at users dot sourceforge dot net
GCC build triplet: i386-unknown-freebsd6.3
GCC host triplet: i386-unknown-freebsd6.3
GCC target triplet: m68k-unknown-amigaos
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42863
[Bug c++/42824] [4.5 regression] c++ compilation complains about error: call of overloaded
--- Comment #11 from redi at gcc dot gnu dot org 2010-01-25 19:44 --- Confirmed pr42824.cc: In member function void EvalT::eval(int_0) [with int V = 0, T = Mtrl]: pr42824.cc:42:9: instantiated from void EvalT::eval() [with int V = 0, T = Mtrl] pr42824.cc:65:20: instantiated from here pr42824.cc:57:9: error: call of overloaded value(EvalMtrl::WrapQuan0 ) is ambiguous pr42824.cc:49:10: note: candidates are: void EvalT::value(EvalT::WrapQuanV2 ) [with int V = 0, int V2 = 0, T = Mtrl] pr42824.cc:52:10: note: void EvalT::value(EvalT::WrapQuan0 ) [with int V = 0, T = Mtrl] -- redi at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Known to work||4.4.2 Last reconfirmed|-00-00 00:00:00 |2010-01-25 19:44:07 date|| Summary|c++ compilation complains |[4.5 regression] c++ |about error: call of|compilation complains about |overloaded |error: call of overloaded http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42824
[Bug middle-end/42863] [4.5] Regression whith auto increments
--- Comment #2 from schwab at linux-m68k dot org 2010-01-25 19:44 --- m68k-unknown-amigaos is not a valid target. -- schwab at linux-m68k dot org changed: What|Removed |Added GCC build triplet|i386-unknown-freebsd6.3 | GCC host triplet|i386-unknown-freebsd6.3 | GCC target triplet|m68k-unknown-amigaos|m68k-elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42863
[Bug debug/42861] [4.4/4.5 Regression] Spill slots not tracked during var-tracking
--- Comment #2 from aoliva at gcc dot gnu dot org 2010-01-25 19:46 --- Mine. Got a patch. -- aoliva at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |aoliva at gcc dot gnu dot |dot org |org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42861
[Bug c++/42824] [4.5 regression] c++ compilation complains about error: call of overloaded
--- Comment #12 from redi at gcc dot gnu dot org 2010-01-25 19:47 --- CC'ing a release manager -- redi at gcc dot gnu dot org changed: What|Removed |Added CC||jakub at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42824
[Bug c++/42824] [4.5 regression] c++ compilation complains about error: call of overloaded
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42824
[Bug testsuite/42854] [4.4/4.5 Regression] FAIL: gcc.dg/darwin-weakimport-[13].c scan-assembler-not *
--- Comment #4 from howarth at nitro dot med dot uc dot edu 2010-01-25 20:20 --- Mike Stump's comment on Geoff's implementation of the attribute weak_import in FSF gcc is... Not earth shattering, it just sets .weak_definition or .weak_reference for the assembler. google can find tidbits about the programming model, how they are used and the assembler manual and so on... if your curious. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42854
[Bug c++/42864] New: std::String Constructor segfault
$ cat test.cpp
#include string
int main()
{
std::string( (unsigned) 2, (unsigned) 'M' );
}
$ gcc -v
Using built-in specs.
Target: arm-linux-gnueabi
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.3.3-5ubuntu4'
--with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3
--program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug
--enable-objc-gc --enable-mpfr --disable-libssp --disable-sjlj-exceptions
--with-arch=armv5t --with-tune=cortex-a8 --enable-checking=release
--build=arm-linux-gnueabi --host=arm-linux-gnueabi --target=arm-linux-gnueabi
Thread model: posix
gcc version 4.3.3 (Ubuntu 4.3.3-5ubuntu4)
$ g++ -v -save-temps test.cpp ./a.out
Using built-in specs.
Target: arm-linux-gnueabi
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.3.3-5ubuntu4'
--with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3
--program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug
--enable-objc-gc --enable-mpfr --disable-libssp --disable-sjlj-exceptions
--with-arch=armv5t --with-tune=cortex-a8 --enable-checking=release
--build=arm-linux-gnueabi --host=arm-linux-gnueabi --target=arm-linux-gnueabi
Thread model: posix
gcc version 4.3.3 (Ubuntu 4.3.3-5ubuntu4)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-shared-libgcc' '-march=armv5t'
'-mtune=cortex-a8'
/usr/lib/gcc/arm-linux-gnueabi/4.3.3/cc1plus -E -quiet -v -D_GNU_SOURCE
test.cpp -D_FORTIFY_SOURCE=2 -march=armv5t -mtune=cortex-a8 -fpch-preprocess -o
test.ii
ignoring nonexistent directory /usr/local/include/arm-linux-gnueabi
ignoring nonexistent directory
/usr/lib/gcc/arm-linux-gnueabi/4.3.3/../../../../arm-linux-gnueabi/include
ignoring nonexistent directory /usr/include/arm-linux-gnueabi
#include ... search starts here:
#include ... search starts here:
/usr/include/c++/4.3
/usr/include/c++/4.3/arm-linux-gnueabi
/usr/include/c++/4.3/backward
/usr/local/include
/usr/lib/gcc/arm-linux-gnueabi/4.3.3/include
/usr/lib/gcc/arm-linux-gnueabi/4.3.3/include-fixed
/usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-shared-libgcc' '-march=armv5t'
'-mtune=cortex-a8'
/usr/lib/gcc/arm-linux-gnueabi/4.3.3/cc1plus -fpreprocessed test.ii -quiet
-dumpbase test.cpp -march=armv5t -mtune=cortex-a8 -auxbase test -version -o
test.s
GNU C++ (Ubuntu 4.3.3-5ubuntu4) version 4.3.3 (arm-linux-gnueabi)
compiled by GNU C version 4.3.3, GMP version 4.2.4, MPFR version 2.4.0.
GGC heuristics: --param ggc-min-expand=64 --param ggc-min-heapsize=64454
Compiler executable checksum: adaaa2547d753dbc1889caf45cfd272e
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-shared-libgcc' '-march=armv5t'
'-mtune=cortex-a8'
as -march=armv5t -meabi=4 -o test.o test.s
COMPILER_PATH=/usr/lib/gcc/arm-linux-gnueabi/4.3.3/:/usr/lib/gcc/arm-linux-gnueabi/4.3.3/:/usr/lib/gcc/arm-linux-gnueabi/:/usr/lib/gcc/arm-linux-gnueabi/4.3.3/:/usr/lib/gcc/arm-linux-gnueabi/:/usr/lib/gcc/arm-linux-gnueabi/4.3.3/:/usr/lib/gcc/arm-linux-gnueabi/
LIBRARY_PATH=/usr/lib/gcc/arm-linux-gnueabi/4.3.3/:/usr/lib/gcc/arm-linux-gnueabi/4.3.3/:/usr/lib/gcc/arm-linux-gnueabi/4.3.3/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-shared-libgcc' '-march=armv5t'
'-mtune=cortex-a8'
/usr/lib/gcc/arm-linux-gnueabi/4.3.3/collect2 --eh-frame-hdr -dynamic-linker
/lib/ld-linux.so.3 -X -m armelf_linux_eabi -z relro
/usr/lib/gcc/arm-linux-gnueabi/4.3.3/../../../crt1.o
/usr/lib/gcc/arm-linux-gnueabi/4.3.3/../../../crti.o
/usr/lib/gcc/arm-linux-gnueabi/4.3.3/crtbegin.o
-L/usr/lib/gcc/arm-linux-gnueabi/4.3.3 -L/usr/lib/gcc/arm-linux-gnueabi/4.3.3
-L/usr/lib/gcc/arm-linux-gnueabi/4.3.3/../../.. test.o -lstdc++ -lm -lgcc_s
-lgcc -lc -lgcc_s -lgcc /usr/lib/gcc/arm-linux-gnueabi/4.3.3/crtend.o
/usr/lib/gcc/arm-linux-gnueabi/4.3.3/../../../crtn.o
Segmentation fault
--
Summary: std::String Constructor segfault
Product: gcc
Version: 4.3.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kasey dot erickson at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42864
[Bug c++/42864] std::String Constructor segfault
--- Comment #1 from kasey dot erickson at gmail dot com 2010-01-25 20:23 --- Created an attachment (id=19705) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19705action=view) preprocessed file output from -save-temps -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42864
[Bug rtl-optimization/36712] Inefficient loop unrolling
--- Comment #8 from froydnj at gcc dot gnu dot org 2010-01-25 21:10 ---
First, something has gotten better; an arm-eabi gcc (-O2 -std=c99 -mcpu=arm9
-funroll-loops) from 20091209 gives:
Unroll:
@ Function supports interworking.
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
stmfd sp!, {r4, r5, r6, r7, r8}
add r8, r1, #256
.L2:
ldr ip, [r1, #0]
mov r7, r1
mul r2, ip, r0
str r2, [r7], #4
ldr r3, [r1, #4]
ldr r5, [r7, #4]
mul r6, r3, r0
str r6, [r7, #0]
ldr r4, [r1, #12]
ldr ip, [r1, #16]
add r2, r1, #20
ldmia r2, {r2, r3, r7}@ phole ldm
mul r6, r5, r0
mul r5, r4, r0
mul r4, ip, r0
mul ip, r2, r0
mul r2, r3, r0
mul r3, r7, r0
str r6, [r1, #8]
str r5, [r1, #12]
str r4, [r1, #16]
str ip, [r1, #20]
str r2, [r1, #24]
add r1, r1, #32
cmp r1, r8
str r3, [r1, #-4]
bne .L2
ldmfd sp!, {r4, r5, r6, r7, r8}
bx lr
.size Unroll, .-Unroll
.ident GCC: (GNU) 4.5.0 20091209 (experimental)
which, if not close to ManualUnroll from the first comment, is much better than
the initial example.
Second, the problem Daniel mentioned concerning auto-inc/dec not doing the
right thing is because of the cleverness of
loop-unroll.c:analyze_iv_to_split_insn. It breaks the code shape that
auto-inc/dec needs. (You can see its effects in the assembly above; the
spurious move to r7 at the top of the loop.) Even if you disable that bit of
RTL loop unrolling, you also need to disable the web pass so as to not really
break the code shape for auto-inc/dec and introduce spurious moves into the
RTL. Once you do that, you get:
Unroll:
@ Function supports interworking.
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
add ip, r1, #256
.L2:
ldr r2, [r1, #0]
mul r3, r2, r0
str r3, [r1], #4
ldr r2, [r1, #0]
mul r3, r2, r0
str r3, [r1], #4
ldr r2, [r1, #0]
mul r3, r2, r0
str r3, [r1], #4
ldr r2, [r1, #0]
mul r3, r2, r0
str r3, [r1], #4
ldr r2, [r1, #0]
mul r3, r2, r0
str r3, [r1], #4
ldr r2, [r1, #0]
mul r3, r2, r0
str r3, [r1], #4
ldr r2, [r1, #0]
mul r3, r2, r0
str r3, [r1], #4
ldr r2, [r1, #0]
mul r3, r2, r0
str r3, [r1], #4
cmp r1, ip
bne .L2
bx lr
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36712
[Bug fortran/42865] New: OpenMP threadprivate allocatable saved variable - seg fault
For this code:
program F03_2_9_4_1_1a
implicit none
logical :: fail = .false.
call sub1(fail)
if (fail) stop 1
contains
subroutine sub1(fail)
use omp_lib
implicit none
integer, parameter :: NT = 4
logical :: fail
integer :: i
real, allocatable, save :: A(:)
real :: correct_result(NT) ! if (A = correct_result) then test passes
!$omp threadprivate(A)
allocate(A(NT))
call omp_set_num_threads(NT)
call omp_set_dynamic(.false.)
call random_number(correct_result)
A = correct_result
!$omp parallel copyin(A)
! Each thread checks its threadprivate copy of A in a critical region to
! attempt to avoid mangling any output.
!$omp critical
do i = 1,NT
! correct_result has shared data-sharing attribute by default
if (A(i) /= correct_result(i)) then
print *, 'FAIL: omp_get_thread_num() == ', omp_get_thread_num(),
' A(', i, ') = ', A(i), '(expected ', correct_result(i), ')'
fail = .true.
end if
end do
!$omp end critical
!$omp end parallel
end subroutine sub1
end program F03_2_9_4_1_1a
gfortran -fopenmp test.f90
./a.out
Segmentation fault
Information from the OpenMP testers:
! NOTES
! In OpenMP 2.5, ALLOCATABLE arrays were not allowed in a copyin clause.
!
! OpenMP 3.0, p. 102, line 17 states Each thread's copy of that array must
! be allocated with the same bounds. This seems to imply that the
! programmer must explicitly allocate each thread's copy of the array, but
! p. 101, lines 22-24 states On entry to any parallel region, each
thread's
! copy of a variable that is affected by a copyin clause for the parallel
! region will acquire the allocation... status of the master thread's copy.
!
! REFERENCES
!OpenMP 3.0, p. 85, lines 12-13 (SAVE attribute needed if not in module
! or main (F08))
!OpenMP 3.0, p. 102, line 17
!OpenMP 3.0, p. 316, lines 18-20
The error appears to be internal to the OpenMP library:
Program terminated with signal 11, Segmentation fault.
#0 0x0044f150 in memcpy ()
(gdb) where
#0 0x0044f150 in memcpy ()
#1 0x0040077e in sub1.1533.omp_fn.0 (.omp_data_i=0x7fffbbc0) at
ISU3230.f90:46
#2 0x0041eea6 in gomp_thread_start (xdata=value optimized out)
at ../../../xt-gcc-4.4.2/libgomp/team.c:115
#3 0x004163d3 in start_thread ()
#4 0x00454eb9 in clone ()
#5 0x in ?? ()
(gdb) q
The code does execute without error with another compiler.
--
Summary: OpenMP threadprivate allocatable saved variable - seg
fault
Product: gcc
Version: 4.4.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: longb at cray dot com
GCC build triplet: x86_64-suse-linux
GCC host triplet: x86_64-suse-linux
GCC target triplet: x86_64-suse-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42865
[Bug c++/42864] std::String Constructor segfault
--- Comment #2 from redi at gcc dot gnu dot org 2010-01-25 21:29 --- *** This bug has been marked as a duplicate of 42261 *** -- redi at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42864
[Bug libstdc++/42261] infinite recursion from string(string::size_type(6), string::size_type('f'))
--- Comment #15 from redi at gcc dot gnu dot org 2010-01-25 21:29 --- *** Bug 42864 has been marked as a duplicate of this bug. *** -- redi at gcc dot gnu dot org changed: What|Removed |Added CC||kasey dot erickson at gmail ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42261
[Bug fortran/42866] New: ICE for REDUCTION with ALLOCATABLE array as variable on SECTIONS
For this test case:
program F03_2_9_3_6_2c
! derived from OpenMP test omp3f/F03_2_9_3_6_2c.f90
! REFERENCES
! OpenMP 3.0, p. 100, lines 10-12
! OpenMP 3.0, p. 316, lines 18-22
use omp_lib
implicit none
integer, parameter :: NT = 4
integer :: thread_num1, thread_num2, thread_num3
integer, allocatable :: thread_num_sums(:)
integer :: i
call omp_set_dynamic(.false.)
call omp_set_num_threads(NT)
allocate(thread_num_sums(NT))
thread_num_sums = 0
!$omp parallel
!$omp sections reduction(+:thread_num_sums)
!$omp section
thread_num_sums = omp_get_thread_num()
thread_num1 = omp_get_thread_num()
!$omp section
thread_num_sums = omp_get_thread_num()
thread_num2 = omp_get_thread_num()
!$omp section
thread_num_sums = omp_get_thread_num()
thread_num3 = omp_get_thread_num()
!$omp end sections
!$omp end parallel
do i = 1, NT
if (thread_num_sums(i) /= thread_num1+thread_num2+thread_num3) then
write (*,fmt=('FAIL - thread_num_sums(',i2, ') == ',i10,
' (expected',i2,')'))
i, thread_num_sums(i), thread_num1+thread_num2+thread_num3
else
write (*,fmt=('thread',i2,' thread_num_sums(i) = ',i2))
i, thread_num_sums(i)
end if
end do
end program F03_2_9_3_6_2c
the compiler aborts:
gfortran -fopenmp test.f90
test.f90: In function 'f03_2_9_3_6_2c':
test.f90:20: internal compiler error: in single_pred_edge, at basic-block.h:658
Please submit a full bug report,
with preprocessed source if appropriate.
Additional comment from the OpenMP testers:
The GNU gfortran compiler gets an internal error when compiling this
test case when the REDUCTION appears on a SECTIONS.
The OpenMP API version 3 (May 2008) p. 316 lines 18-20 states:
In Version 3.0, Fortran allocatable arrays may appear in ...
reduction ... clauses.
The API also states on p. 100 line 10-23:
An original list item with the ALLOCATABLE attribute must be in the
allocated state at entry to the construct containing the reduction clause.
Additionally, the list item must not be deallocated and/or allocated
within the region.
--
Summary: ICE for REDUCTION with ALLOCATABLE array as variable on
SECTIONS
Product: gcc
Version: 4.4.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: longb at cray dot com
GCC build triplet: x86_64-suse-linux
GCC host triplet: x86_64-suse-linux
GCC target triplet: x86_64-suse-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42866
[Bug testsuite/42854] [4.4/4.5 Regression] FAIL: gcc.dg/darwin-weakimport-[13].c scan-assembler-not *
--- Comment #5 from dominiq at lps dot ens dot fr 2010-01-25 21:59 --- Mike Stump's comment on Geoff's implementation of the attribute weak_import in FSF gcc is... Could you give a pointer? The first test was introduced by this patch http://gcc.gnu.org/ml/gcc-patches/2004-10/msg02441.html and updated by this one http://gcc.gnu.org/ml/gcc-patches/2005-01/msg00146.html The second test was introduce by this patch http://gcc.gnu.org/ml/gcc-patches/2005-12/msg00378.html Note the introduction: weak_import is more-or-less deprecated on Darwin, by which I mean that it has a bunch of known bugs but we aren't trying very hard to convince people to stop using it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42854
[Bug c/42867] New: isfinite macro defined for 4.4.1 but not for 4.3.3
The problem is that the definition of isfinite() macro is not consistent
between version of GCC 4.3.3 and 4.4.1.
Simple test program:
include math.h
#ifdef isfinite
#error isfinite defined
#else
#error isfinite NOT defined
#endif
int main() { return 0; }
1) Test with GCC 4.4.1 (Ubuntu 9.10 x86-64)
mlos...@dog:~/tmp$ gcc --version
gcc (Ubuntu 4.4.1-4ubuntu9) 4.4.1
mlos...@dog:~/tmp$ gcc isfinite.c
isfinite.c:3:2: error: #error isfinite defined
mlos...@dog:~/tmp$
2) Test with GCC 4.3.3 (Ubuntu 9.04 x86-32)
mlos...@vb-ubuntu904:~/tmp$ gcc --version
gcc (Ubuntu 4.3.3-5ubuntu4) 4.3.3
mlos...@vb-ubuntu904:~/tmp$ gcc isfinite.c
isfinite.c:5:2: error: #error isfinite NOT defined
In the 2nd case, it seems to be required to use compiler option -std=c99 to
enable the macro:
mlos...@vb-ubuntu904:~/tmp$ gcc -std=c99 isfinite.c
isfinite.c:3:2: error: #error isfinite defined
I think the behaviour of version 4.3.3. is incorrect.
I didn't find any related reports, except the one for C++ use of iostream.h
together with math.h (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14608).
But I am sure it is not related to this report.
--
Summary: isfinite macro defined for 4.4.1 but not for 4.3.3
Product: gcc
Version: 4.3.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mateusz at loskot dot net
GCC host triplet: x86_64-*-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42867
[Bug c/42867] isfinite macro defined for 4.4.1 but not for 4.3.3
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-01-25 22:26 --- isfinite is C99 only. Plus math.h is controlled by libc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42867
[Bug c++/42864] std::String Constructor segfault
--- Comment #3 from paolo dot carlini at oracle dot com 2010-01-25 22:30 --- Boy, this curious way of constructing strings seems rather fancy lately ;) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42864
[Bug c/42867] isfinite macro defined for 4.4.1 but not for 4.3.3
--- Comment #2 from mateusz at loskot dot net 2010-01-25 22:34 --- (In reply to comment #1) isfinite is C99 only. Yes, of course it is and I understand it, but I'm trying to understand why the GCC 4.3 and 4.4. behave differently? Does it mean GCC 4.4 makes C99 elements available without explicit request? It looks as such, then it is a bug and GCC 4.3 is correct. Plus math.h is controlled by libc. Means, I reported to wrong place? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42867
[Bug c/42867] isfinite macro defined for 4.4.1 but not for 4.3.3
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-01-25 22:37 --- It depends. But really you did report it to us rather than Ubuntu first as both are modified versions of GCC. Also you should look to see if they are using the same version of glibc. Because maybe glibc was fixed with newer versions glibc. If that is the case there is nothing we can do really. And this bug is invalid. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42867
[Bug middle-end/42694] Compiler could optimize pow (x, 0.75) into sqrt (x) * sqrt (sqrt (x))
--- Comment #3 from meissner at gcc dot gnu dot org 2010-01-26 00:40 --- Created an attachment (id=19706) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19706action=view) Proposed patch to fix the problem Patch to add 3 new switches to tune whether to use a combination of sqrt/cbrt to replace pow. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42694
[Bug target/42868] New: 4.4.3 ICE in change_address_1 on sparc64
The following test case ICEs gcc-4.4.3 on sparc64 when compiled with -fPIC -m64
and any optimization level = -O1.
cat cpu_stats.i
extern int end, etext, edata;
long util_print_cpu_stats(void)
{
long vm_text, vm_init_data, vm_uninit_data, vm_sbrk_data;
vm_text = (long) (((long) (etext)) / 1024.0 + 0.5);
vm_init_data = (long) (((long) (edata) - (long) (etext)) / 1024.0 + 0.5);
vm_uninit_data = (long) (((long) (end) - (long) (edata)) / 1024.0 + 0.5);
vm_sbrk_data = (long) (((long) sbrk(0) - (long) (end)) / 1024.0 + 0.5);
return vm_text + vm_init_data + vm_uninit_data + vm_sbrk_data;
}
sparc64-unknown-linux-gcc -O3 -fPIC -m64 -c cpu_stats.i
cpu_stats.i: In function 'util_print_cpu_stats':
cpu_stats.i:13: internal compiler error: in change_address_1, at
emit-rtl.c:1954
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
sparc64-unknown-linux-gcc -v
Using built-in specs.
Target: sparc64-unknown-linux
Configured with: /tmp/gcc-4.4.3/configure --target=sparc64-unknown-linux
--with-cpu=ultrasparc --prefix=/home/mikpe/pkgs/linux-x86_64/cross-sparc64
--with-gmp=/home/mikpe/pkgs/linux-x86_64/gmp-4.3.2
--with-mpfr=/home/mikpe/pkgs/linux-x86_64/mpfr-2.4.2 --disable-nls
--disable-shared --disable-libmudflap --disable-multilib --enable-threads=posix
--enable-checking=release --enable-languages=c
Thread model: posix
gcc version 4.4.3 (GCC)
Replacing -m64 with -m32 or dropping -fPIC eliminates the ICE.
4.3.4 and current 4.5.0 do not ICE. For 4.5.0 the ICE was cured by r149082 (the
fix for PR40416), however applying that fix to 4.4.3 does not eliminate the ICE
there.
Above I used a cross hosted on x86, but the ICE also occurs in a native sparc64
build.
The bug was first reported to Debian (#566242). I reduced the test case and did
a reghunt on trunk in the hope finding a backportable fix.
--
Summary: 4.4.3 ICE in change_address_1 on sparc64
Product: gcc
Version: 4.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mikpe at it dot uu dot se
GCC target triplet: sparc64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42868
[Bug target/42868] 4.4.3 ICE in change_address_1 on sparc64
--- Comment #1 from mikpe at it dot uu dot se 2010-01-26 01:36 --- Created an attachment (id=19707) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19707action=view) test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42868
[Bug c/42869] New: GOMP_critical_start wrong on Itanium due to __sync miscompilation
The Itanium code for GOMP_start_critical starts 0x20334900 GOMP_critical_start: [MMI] alloc r16=ar.pfs,1,1,0 0x20334901 GOMP_critical_start+1: addl r32=840,r1 0x20334902 GOMP_critical_start+2: nop.i 0x0 0x20334910 GOMP_critical_start+16:[MMI] mf;; 0x20334911 GOMP_critical_start+17:mov.m ar.ccv=0 0x20334912 GOMP_critical_start+18:mov r14=1;; 0x20334920 GOMP_critical_start+32:[MMI] nop.m 0x0 0x20334921 GOMP_critical_start+33: cmpxchg4.rel r14=[r32],r14,ar.ccv 0x20334922 GOMP_critical_start+34:nop.i 0x0;; 0x20334930 GOMP_critical_start+48:[MIB] nop.m 0x0 0x20334931 GOMP_critical_start+49:cmp.eq p6,p7=0,r14 0x20334932 GOMP_critical_start+50: (p06) br.ret.dptk.many b0;; Note the mf followed by a cmxchg4.rel. I don't believe this enforces sufficient memory ordering constraints. A subsequent store from inside the critical section may become visible to other threads before the cmpxchg4.rel, which is only intended to prevent reordering in the OTHER direction. Thus a store inside the critical section can become visible before the lock is really acquired, which is, at least theoretically, very bad. I do not know whether current hardware may actually execute these out of order. I observed this while trying to understand the GNU OpenMP support. I also don't know whether this problem is limited to Itanium. I expect it doesn't exist on X86. It may exist onother weakly-ordered architectures. I believe that this is due to incorrect code generated for the __sync_bool_compare_and_swap in gomp_mutex_lock(). -- Summary: GOMP_critical_start wrong on Itanium due to __sync miscompilation Product: gcc Version: 4.4.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: Hans dot Boehm at hp dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42869
[Bug target/42841] [4.3/4.4/4.5 Regression] SH: Assembler complains pcrel too far.
--- Comment #11 from chrbr at gcc dot gnu dot org 2010-01-26 07:20 --- Subject: Bug 42841 Author: chrbr Date: Tue Jan 26 07:20:27 2010 New Revision: 156229 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156229 Log: fix PR target/42841 Modified: trunk/gcc/ChangeLog trunk/gcc/config/sh/sh.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42841
[Bug target/42841] [4.3/4.4/4.5 Regression] SH: Assembler complains pcrel too far.
--- Comment #12 from chrbr at gcc dot gnu dot org 2010-01-26 07:22 --- Subject: Bug 42841 Author: chrbr Date: Tue Jan 26 07:21:57 2010 New Revision: 156230 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156230 Log: fix PR target/42841 Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/config/sh/sh.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42841
