--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-02-22
09:47 ---
Hum, this one is really tricky. It's indeed an aliasing problem and I think
your reduced, reduced testcase demonstrates that there might be a hole in the
flow-insensitive alias analysis for pointers
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-02-22
09:51 ---
Actually I do not see the interest, since the test is wrong.
I would simply cvs remove it.
I was under the impression that moving it to the norun.lst was the canonical
procedure when waiting
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-02-23
09:01 ---
Tests removed.
--
What|Removed |Added
Status|NEW
--
What|Removed |Added
Target Milestone|--- |4.0.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19902
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-02-23
09:30 ---
Not sure why, but fixed as of today.
--
What|Removed |Added
Status|NEW
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-02-23
10:35 ---
Confirmed, a regression introduced with:
Wed Sep 9 01:32:01 1998 David S. Miller [EMAIL PROTECTED]
Add preliminary native sparcv9 Solaris support.
* configure.in: Recognize sparv9
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-02-23
10:35 ---
Taking care of the patch.
--
What|Removed |Added
AssignedTo|unassigned at gcc
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-02-23
12:00 ---
http://gcc.gnu.org/ml/gcc-patches/2005-02/msg01405.html
Thanks for the bug report and the fix!
--
What|Removed |Added
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-02-23
23:08 ---
It should be fixed by the next push from AdaCore.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19140
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-02-24
15:59 ---
New test case exhibits same problem.
Confirmed. Reduced testcase:
struct demo {
int s;
};
extern struct demo * const *xd;
static inline struct demo *fn1(void) __attribute__((pure));
static
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-02-24
16:49 ---
Hum... again a consequence of the C++ front-end not setting TREE_SIDE_EFFECTS on
every CALL_EXPR, like the C front-end. The sequence of events is as follows:
1. fn1()-s -= 1 is expanded to the 3-operand
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-02-24
17:06 ---
Note that I don't plan to work on this in the very near future, as the problem
is no breaking news and doesn't appear to cause much harm in practice.
--
What|Removed
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-03-01
18:33 ---
It should be fixed by the next push from AdaCore.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18727
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-03-01
19:52 ---
Fixing.
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |ebotcazou
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-03-02
08:01 ---
If -fno-strict-aliasing fixes the problem, then you have an aliasing problem
in the source. So closing as invalid.
Ugh! If compilers were that simple... -fno-strict-aliasing disables a whole
class
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-03-03
19:25 ---
It really seems like the C++ front end is doing the right thing,
abstractly -- these functions don't have side-effects! So, either the
inliner or stabilize reference seems like it needs fixing
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-03-03
21:12 ---
I don't think I'd try to be that clever. We might want the
stabilization to occur even in other cases. In looking at it more
closely, it definitely looks like stabilize_reference should deal
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-03-03
22:02 ---
There are other places where TREE_SIDE_EFFECTS matters. (Like, do we
have to emit this expression at all, if its result is not used?)
OK.
The counter to your argument is that I don't see why the C
--
What|Removed |Added
CC||ebotcazou at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-03-04
18:10 ---
Surely this is the same as bug 19933?
Right, Duplicates with a big D. :-)
*** This bug has been marked as a duplicate of 19933 ***
--
What|Removed |Added
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-03-04
18:10 ---
*** Bug 20317 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-03-04
18:11 ---
Confirmed by duplicate.
--
What|Removed |Added
CC
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-03-06
11:54 ---
Confirmed, worked only by accident.
--
What|Removed |Added
Status
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-03-06
11:55 ---
It should be fixed by the next push from AdaCore.
--
What|Removed |Added
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-03-06
11:56 ---
The change comes from:
2004-11-28 Matt Kraai [EMAIL PROTECTED]
PR diagnostic/17594
* opts.c (find_opt): Require that the input match a switch exactly
or that the switch take
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-03-07
09:54 ---
An interesting thing in the head comment of unsafe_for_reeval in 3.4.x:
This assumes that CALL_EXPRs and TARGET_EXPRs are never replicated in
an expression tree, so that it safe to unsave them
--
What|Removed |Added
CC||ebotcazou at gcc dot gnu dot
||org
GCC build triplet
--
What|Removed |Added
CC||ebotcazou at gcc dot gnu dot
||org
Component|c
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-03-10
08:04 ---
New patch at http://gcc.gnu.org/ml/gcc-patches/2005-03/msg00864.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17972
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-03-10
19:40 ---
Confirmed:
pr20412.c: In function 'foo':
pr20412.c:20: internal compiler error: RTL check: expected elt 0 type 'e' or
'u', have 'i' (rtx reg) in simplify_set, at combine.c:5145
Please submit a full bug
--
What|Removed |Added
CC||jason at redhat dot com
AssignedTo|ebotcazou at gcc dot gnu dot|unassigned at gcc dot gnu
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-03-12
23:15 ---
It's 4.1.0 if I read correctly.
--
What|Removed |Added
CC
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-03-15
16:25 ---
Fixed on mainline.
--
What|Removed |Added
Status|ASSIGNED
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-03-16
07:56 ---
The problem occurs only with GCC 4.x, in particular not with GCC 3.4.3.
--
What|Removed |Added
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-03-16
09:01 ---
Recategorizing.
--
What|Removed |Added
Component|target
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-03-16
10:24 ---
With Sun as, I get
as: sugarconverter.s, line 873: error: can't compute difference between
symbols in different segments
for the same function (which is slightly more descriptive).
--
What
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-03-16
10:26 ---
Investigating, but STABS+ is crippled in GCC 4.x.
--
What|Removed |Added
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-03-16
10:53 ---
Confirmed, but the question is why do you need to generate the PCH twice?
Header files never produce object files, unlike in Ada. Also removing the PCH
file is enough to solve the problem
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-03-16
15:55 ---
This was strange to read, because I've definitely noticed it with 3.4.3.
Interestingly, it seems to be only g++, rather than gcc, that has the problem:
plg2=; cat g7.c
register void *tp __asm__(%g7
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-03-17
10:28 ---
Perhahs, I have a concept problem. If you have a c++ template in a .h
file without a .c file and you compile it you should obtain a .o object.
No, you're forcing the compilation with -x c
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-03-17
15:10 ---
Fixed in 4.0.0.
--
What|Removed |Added
Target Milestone|4.1.0
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-03-17
15:39 ---
Fixed in 4.0.0.
--
What|Removed |Added
Target Milestone|4.1.0
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-03-17
18:50 ---
Fixed in 4.0.0.
--
What|Removed |Added
Target Milestone|4.1.0
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-03-17
18:50 ---
Fixed in 4.0.0.
--
What|Removed |Added
Target Milestone|4.1.0
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-03-17
19:57 ---
Fixed in 4.0.0.
--
What|Removed |Added
Target Milestone|4.1.0
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-03-17
19:59 ---
Fixed in 4.0.0.
--
What|Removed |Added
Target Milestone|4.1.0
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-03-19
15:38 ---
Uncovered by a front-end change. Not sure it can work on 64-bit machines now.
--
What|Removed |Added
--
What|Removed |Added
CC||ebotcazou at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla
--
What|Removed |Added
CC||ebotcazou at gcc dot gnu dot
||org
Summary
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-03-24
22:24 ---
Wouldn't it be better to have DECL_ASSEMBLER_NAME use the real name? What's
the
background onthe change to DECL_ASSEMBLER_NAME?
Define real name. In 3.4.x, as discovered by Richard, the C and C
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-03-28
11:57 ---
Confirmed.
--
What|Removed |Added
CC
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-03-29
12:23 ---
Fixed in 4.x.
--
What|Removed |Added
Status|ASSIGNED
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-03-29
14:08 ---
Workaround: -fdelayed-branch (enabled at -O and above).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20446
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-03-29
16:38 ---
I'll backport the fix to 4.0 as per Richard's request.
--
What|Removed |Added
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-03-29
18:54 ---
Maybe this can be fixed by disabling PCH generation when -x is passed.
--
What|Removed |Added
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-03-29
18:56 ---
No feedback in 3 months.
--
What|Removed |Added
Status|WAITING
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-03-29
18:58 ---
No feedback in 3 months.
--
What|Removed |Added
Status|WAITING
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-03-29
19:19 ---
Confirmed in 3.4.x, probably another incarnation of the infamous stack slot
sharing problem in 3.x when type-based aliasing is enabled.
As as side note, -fschedule-insns makes little sense without -mcpu
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-03-29
19:41 ---
The code is invalid: you're dereferencing a t_m pointer through a cast to
pointer to t_u. Now the structures don't have the same alignment (t_m is 32-bit
aligned while t_u is 64-bit aligned). I guess
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-03-29
19:43 ---
Investigating.
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-03-30
10:53 ---
Hum... type-punning simply doesn't work in this case with the C++ compiler, but
does work with the C compiler. The problem is that:
union u {
x_uint64_t first;
x_uint32_t
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-03-31
08:16 ---
'section' is not a machine attribute, it's an attribute of C-like languages.
The compiler is correct in rejecting it. Use pragma Linker_Section instead.
--
What|Removed
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-04-04
14:54 ---
Recategorizing.
--
What|Removed |Added
Component|debug
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-04-04
15:42 ---
See http://gcc.gnu.org/ml/gcc-patches/2005-04/msg00359.html
--
What|Removed |Added
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-04-04
15:48 ---
Patch backported.
--
What|Removed |Added
Status|ASSIGNED
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-04-04
17:21 ---
Target removed.
--
What|Removed |Added
Status|SUSPENDED
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-04-04
17:21 ---
Target removed.
--
What|Removed |Added
Status|SUSPENDED
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-04-05
07:18 ---
See http://gcc.gnu.org/ml/gcc-patches/2005-03/msg02709.html
--
What|Removed |Added
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-04-07
06:56 ---
It only fails on mainline now.
--
What|Removed |Added
Summary|[4.0/4.1
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-04-07
06:57 ---
It only fails on mainline now.
--
What|Removed |Added
Summary|ACATS cdd2a02
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-04-08
08:53 ---
Thanks for confirming.
--
What|Removed |Added
Status|RESOLVED
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-04-13
21:55 ---
I can reproduce neither with a bootstrapped compiler on sparc-sun-solaris2.8,
nor with a built compiler on sparc-sun-solaris2.5.1, nor with a cross to
sparc-linux from x86_64-suse-linux.
Have you changed
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-04-14
06:27 ---
I'm interested too. :-) FWIW, when I did the transition on SPARC, I compared
the assembly code generated for all testcases in gcc.c-torture/compile at -O2;
IIRC there were a few regressions related
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-04-15
22:07 ---
Confirmed, there is indeed a suspicious cast in the way.
--
What|Removed |Added
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-04-15
22:09 ---
Recategorizing for now.
--
What|Removed |Added
Component|middle-end
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-04-15
22:20 ---
Sorry, I missed this one. Do not hesitate to CC me for SPARC-related problems.
Could you attach the preprocessed file?
--
What|Removed |Added
--
What|Removed |Added
Severity|critical|normal
GCC build triplet||sparc64-portbld-freebsd5.3
GCC target triplet|
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-04-15
22:25 ---
PR libgcj/6461 was opened for the
FAIL: FileHandleGcTest execution - source compiled test
FAIL: FileHandleGcTest execution - gij test
FAIL: FileHandleGcTest execution - bytecode-native test
FAIL
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-04-17
12:59 ---
According to Andrew, the
FAIL: Array_3 execution - gij test
FAIL: Array_3 execution - gij test
failures are expected: optimization is allowed to delete load insns whose
result is unused, even if those
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-04-17
21:13 ---
It's a target problem: FreeBSD overrides this line from sparc.h:
#define CPP_SPEC %(cpp_cpu) %(cpp_arch) %(cpp_endian) %(cpp_subtarget)
with this line from freebsd-spec.h:
/* Provide a CPP_SPEC
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-04-18
09:23 ---
I messed up the quotation too. :-( It should read:
#undef CPP_SPEC
#define CPP_SPEC \
%(cpp_cpu) \
%(cpp_arch) \
%{fPIC|fpic|fPIE|fpie:-D__PIC__ -D__pic_} \
%{posix:-D_POSIX_SOURCE
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-04-19
06:54 ---
The problem has resurfaced on mainline:
http://gcc.gnu.org/ml/gcc/2005-04/msg01052.html
--
What|Removed |Added
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-04-20
17:04 ---
Eric, if you confirm that this bug is fixed in 3.3 and 3.4, then this is a
(latent) regression on mainline and 4.0.
It is indeed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15248
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-04-22
17:38 ---
David, could you help here? I don't think a cross-compiler is necessary.
--
What|Removed |Added
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-04-22
17:42 ---
For that matter, if one cannot build the 64 bit compiler with the stock
compiler
on Debian sparc64-unknown-linux-gnu, how does one build this compiler?
That's a Debian problem, the system compiler
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-04-30
17:10 ---
Fixing.
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |ebotcazou
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-04-30
20:46 ---
Andrew is right, this error usually means that a shared library contains code
that has not been compiled with -fPIC. The Solaris 64-bit runtime linker
doesn't seem to be able to cope with this (unlike
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-04-30
22:10 ---
The same fix was applied to mainline. Jeff, please consider backporting your
patch to 4.0 branch so that we be definitely done with this nasty problem.
--
What|Removed
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-04-30
22:12 ---
No feedback in 3 months.
--
What|Removed |Added
Status|WAITING
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: libfortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ebotcazou at gcc dot gnu dot org
CC: gcc-bugs at gcc dot
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-05-01
12:04 ---
Investigating.
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-05-01
12:12 ---
Basically same problem as PR target/19933.
--
What|Removed |Added
BugsThisDependsOn
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-05-01
12:21 ---
GCC does not yet have __builtin_isfinite or __builtin_isnormal functions;
they
would be generically useful additions if they always avoided falling back to
a library function. __builtin_fpclassify
c954025 c954026 failures
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ebotcazou at gcc dot gnu dot org
CC
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-05-01
13:27 ---
By Rainer:
http://gcc.gnu.org/ml/gcc-testresults/2005-04/msg01800.html
--
What|Removed |Added
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-05-01
16:33 ---
Will take care of the patch.
--
What|Removed |Added
AssignedTo|unassigned at gcc
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-05-02
07:15 ---
I'd be happy to try if you'd tell me where to switch this option
g++ -m64 -fPIC q.cpp -shared -mimpure-text -o libq.so
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21277
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-05-02
07:27 ---
It doesn't help -- the same problem
OK. To further confirm the diagnostic, you could run readelf -r on libq.so and
find out where this R_SPARC_WDISP30 relocation comes from.
--
http://gcc.gnu.org
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-05-02
07:57 ---
readelf -r libq.so | grep R_SPARC_WDISP30gives the following:
OK, the fundamental problem is that you're trying to build shared libraries with
a compiler configured with --disable-shared. That's
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-05-02
09:05 ---
We must link our .so statically with all the gcc stuff to make sure it runs on
every Solaris. Shipping libstd++.so with our shared library is not very
suitable for us, because it makes product download
201 - 300 of 2613 matches
Mail list logo
