--- Comment #2 from kargl at gcc dot gnu dot org 2008-05-30 06:19 ---
(In reply to comment #1)
This could be solved by judicious use of a good source code editor.
Also, we could have the scanner insert a '/n' if a '/r' is found and peeking
ahead does not find a '/n', assuming we
--- Comment #6 from dfranke at gcc dot gnu dot org 2008-05-30 07:19 ---
Fixed in trunk. Closing.
Follow-up: PR36381.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from jv244 at cam dot ac dot uk 2008-05-30 07:40 ---
A few days ago I started a compilation with
[EMAIL PROTECTED]:/data03/vondele/gcc_trunk/CP2K_gcc_2007_06/src gfortran -v
-c --param ggc-min-expand=0 --param ggc-min-heapsize=4096 -O3 -ffast-math
-ftree-vectorize
In fold_unary, CASE_CONVERT, the folding of the conversion into a bitwise AND
is performed only for INTEGER_TYPE, while it could very likely be performed
for BOOLEAN_TYPE and ENUMERAL_TYPE as well:
/* Convert (T)(x c) into (T)x (T)c, if c is an integer
constants (if x has signed
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-05-30 08:05 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC|
In tree-ssa-reassoc.c the code assumes wrongly, that the 'long' scalar type has
pointer size width. This is at least for w64 not true.
As reference see insert_operand_rank(), and find_operand_rank.
--
Summary: Assume that long is scalar size of a pointer
Product: gcc
In tree-ssa-reassoc.c the code assumes wrongly, that the 'long' scalar type has
pointer size width. This is at least for w64 not true.
As reference see insert_operand_rank(), and find_operand_rank.
--
Summary: Assume that long is scalar size of a pointer
Product: gcc
Call clobbering doesn't transitively close the pointed-to sets.
This blocks removal of call-clobbering of variables that have their addresses
stored in local structures.
This also generates wrong code for (-O2 {,-fno-tree-sra} - dependent on
the amount of fixes installed)
extern void abort
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-05-30 09:49 ---
Mine.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-05-30 09:55 ---
It just assume that the size of a pointer is at least the sizeof long so this
only causes a warning. This fact is true for w64 where long is 32bits while
pointers are 64bits.
--
pinskia at gcc dot gnu dot org
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-05-30 09:55 ---
*** This bug has been marked as a duplicate of 36385 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-05-30 09:55 ---
*** Bug 36386 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36385
Hello!
I've got a sigfault while running application on FC9 compiled with gcc4.3.
Here is backtrace:
-
#0 0x0223ec45 in ?? ()
#1 0x0023c8c5 in ?? () from /usr/lib/libstdc++.so.6
#2 0x085a2b23 in __dynamic_cast (from=0x23c8c0, to=0x238298 typeinfo for
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-05-30 10:21 ---
Look into the code rank is actually a number. So we are taking an integer and
storing it into a void* and then we will access it via find_operand_rank which
casts the pointer back to an integer type. operand_rank
--- Comment #5 from ktietz at gcc dot gnu dot org 2008-05-30 10:32 ---
(In reply to comment #4)
I see. So just two misleading warnings are there.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36385
--- Comment #3 from ktietz at gcc dot gnu dot org 2008-05-30 10:14 ---
It true. Just two warnings are shown, but the back-cast of a long to a pointer
on w64 in insert_operand_rank() is evil. If the pointer is on heap, it can be
easily truncated and point to nowhere.
--
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-05-30 10:58 ---
Umm. It's worse.
With -O2 -fno-tree-sra:
extern void abort (void);
struct Foo {
int *p;
} x;
struct Foo __attribute__((noinline))
bar(int *p)
{
struct Foo f;
f.p = p;
return f;
}
void
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-05-30 11:38 ---
It shows really that points-to analysis and call-clobber analysis cannot be
done separately. We try to connect them at a single point, in handle_rhs
call where we add constraints from anything to dereferenced
gimplify_cond_expr creates a lot of garbage later passes need to clean up, e.g.
in the common case where gimplifying COND_EXPR with one branch GOTO_EXPR and
the other NULL, or both GOTO_EXPRs.
if (D.2106 == (struct B *) b)
{
goto D.2124;
}
becomes:
if (D.2106 == b[0]) goto D.2125 else goto
gcc and g++ (all the versions I've ever used) don't give unused variable
warnings in a lot of cases where there are unused variables. Simple sample
code:
int test1 ()
{
int x = 3;
return (2);
}
int test2 ()
{
int x;
x = 3;
return (2);
}
They only give an unused variable warning in
When compiling my code compilation never ends(takes more than 2 hours).
Same source can be compiled on 32bit linux without any problems.
Platforms known to work:
Gentoo linux
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with:
--- Comment #1 from ivan at cvut dot cz 2008-05-30 14:09 ---
Created an attachment (id=15704)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15704action=view)
This source fails to compile
This source uses boost::spirit parser generator. Uses a lot of template
specializations and
Take the following example:
static
int a (void)
{
return a();
}
int
main ()
{
return 0;
}
GCC doesn't warn that a() is an unused function.
This is problematic if you remove all calls to a() from your code. Although a()
uses itself, GCC should warn that no
--- Comment #3 from tromey at gcc dot gnu dot org 2008-05-30 14:25 ---
Subject: Bug 36320
Author: tromey
Date: Fri May 30 14:25:09 2008
New Revision: 136209
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=136209
Log:
gcc/testsuite
PR preprocessor/36320:
*
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-05-30 14:56 ---
This has been fixed in 4.3.0:
t.c:3: warning: 'a' defined but not used
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from tromey at gcc dot gnu dot org 2008-05-30 15:07 ---
Fixed on trunk.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from tromey at gcc dot gnu dot org 2008-05-30 15:15 ---
Not a regression, so I'm closing it.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from jakub at gcc dot gnu dot org 2008-05-30 15:56 ---
Created an attachment (id=15705)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15705action=view)
tuples-pr36389.patch
Very lightly tested patch (basically, make check-target-libgomp still passes,
nothing
--- Comment #32 from lucier at math dot purdue dot edu 2008-05-30 16:01
---
I've decided to test the current ira branch with this problem. I used the
build instructions in comment 24.
With -fno-ira I get the same results as with 4.3.0 (no surprise there).
With -fira I get the time
--- Comment #13 from dnovillo at gcc dot gnu dot org 2008-05-30 16:12
---
Subject: Bug 36245
Author: dnovillo
Date: Fri May 30 16:11:58 2008
New Revision: 136212
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=136212
Log:
2008-05-30 Diego Novillo [EMAIL PROTECTED]
--- Comment #2 from jakub at gcc dot gnu dot org 2008-05-30 16:17 ---
Created an attachment (id=15706)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15706action=view)
tuples-pr36389.patch
Updated patch to optimize even when one of the branches is NULL.
--
jakub at gcc dot gnu
--- Comment #4 from spark at gcc dot gnu dot org 2008-05-30 18:28 ---
I'm still building the compiler to reproduce the problem.
But can somebody try compiling with --param df-double-queue-threshold-factor=0
and see if it helps ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36365
The following code compiles with gcc 3.2.3 and the current Comeau compiler.
However it fails with gcc 4.1.2 and gcc 4.2.3.
class A
{
public:
A(bool) {};
private:
A(const A);
};
class B
{
public:
B(const A) {};
};
int main(void)
{
B b(A(true));
return 0;
}
Gives this error
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-05-30 19:52 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#178
This Defect report changes how () is handled. It seems a bit weird but we
don't implement it. We still implement the way as described in the standard
and do a default initializer and not a value initializer.
An example is:
See title: the target macro TARGET_VECTOR_ALIGNMENT_REACHABLE isn't documented.
It'd be expected so in in gcc/doc/tm.texi.
--
Summary: TARGET_VECTOR_ALIGNMENT_REACHABLE isn't documented
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
See title: the standard md pattern vec_realign_load_M isn't documented.
It'd be expected so in gcc/doc/md.texi, with cross-references to the
codependent TARGET_VECTORIZE_BUILTIN_MASK_FOR_LOAD in gcc/doc/tm.texi (which
speaks of something called REALIGN_LOAD, but as an operation which gives
little
--- Comment #7 from reichelt at gcc dot gnu dot org 2008-05-31 00:51
---
The bug disappeared on mainline between 2008-04-25 and 2008-05-03.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
The following valid testcase triggers an ICE on mainline when compiled with
-fmudflap -O:
=
struct A
{
int i, j;
};
int foo(long long int x)
{
return ((struct A*)x)-j;
}
=
bug.c: In function 'foo':
bug.c:7: internal compiler
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36397
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-05-31 01:21 ---
This is mostly likely due to my forwprop patch for viewconvertexpr. The fix is
to handle vce.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Gcc 4.4 revision 136218 has
FAIL: gcc.dg/pr30286.c execution test
Revision 136209 is OK
--
Summary: [4.4 Regression]: gcc.dg/pr30286.c
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
--- Comment #13 from steve49152 at yahoo dot ca 2008-05-31 02:53 ---
I have tested the fix as backported to 4.2.4 and everything seems fine. I
additionaly discovered code-generation errors in XFree86 4.7.99.17 in the i810
driver which are resolved with the changes. As an extra test I
43 matches
Mail list logo
