--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-07-02
08:08 ---
One option: have gcc/Makefile stamp-as target test build and output
appropriate script to MS Windows BATCH file as.bat.
I tried to copy the assembler in the tree, instead of making a script pointing
to
--- Additional Comments From lehmann at ans-netz dot de 2005-07-02 08:53
---
I can't install APAR IY26685 because it is already included in AIX's ML11 for
4.3.3. - I already have that fix installed.:
All of the selected fixes in your download list are currently installed on your
system
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-07-02
08:55 ---
Created an attachment (id=9192)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9192action=view)
Patch
Attached patch implements the idea of making a special case for mingw32 in
stamp-as,
the following testcase is extracted from WINE.
It is to some degree problematic because BOOL is a signed int,
but we use 1 bit wide bitfields here.
Also the :0 might be a GNU extension.
The problem is that with gcc 3.3.5:
gcc -O2 -o xx xx.c ; ./xx
no output
but with gcc 4.1 branch:
--- Additional Comments From marcus at jet dot franken dot de 2005-07-02
09:00 ---
Created an attachment (id=9193)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9193action=view)
xx.c
testcase extracted from WINE
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22275
--- Additional Comments From falk at debian dot org 2005-07-02 10:17
---
(In reply to comment #4)
The first call of pokus() completely ignores the assigned value of the
variable
r8 -- instead the value '6' into it for the call. The second call assumes the
the register r8 should
Building gcc on i686-pc-mingw32 (with patch from
http://gcc.gnu.org/ml/gcc-patches/2005-05/msg9.html) fails with:
./xgcc -B./ -B/mingw/i686-pc-mingw32/bin/ -isystem
/mingw/i686-pc-mingw32/include -isystem /mingw/i686-pc-mingw32/sys-include
-L/home/FX/ibin/gcc/../ld -O2
--- Additional Comments From giovannibajo at libero dot it 2005-07-02
11:00 ---
Provide a preprocessed testcase, this bug might be target-independent.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22276
On x86_64-linux as of LAST_UPDATED: Sat Jul 2 09:40:45 UTC 2005
+===GNAT BUG DETECTED==+
| 4.1.0 20050702 (experimental) (x86_64-unknown-linux-gnu) GCC error: |
| in first_vi_for_offset, at tree-ssa-structalias.c:2566
--- Additional Comments From laurent at guerby dot net 2005-07-02 13:08
---
cxa4006 and cxa4017 fail the same way (STORAGE_ERROR) as vms_conv.adb.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22212
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-02
14:30 ---
(In reply to comment #10)
The bug is really in cleanup_tree_cfg which is doing the merge of the two BBs.
This patch fixes the problem but I have not yet bootstrapped it yet:
This patch does not bootstrap.
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-02
15:08 ---
3.4.0 also fails on your test so it is not the bit-field changes in 4.0.0 which
caused this.
--
What|Removed |Added
--- Additional Comments From kenner at vlsi1 dot ultra dot nyu dot edu
2005-07-02 16:04 ---
Subject: Re: [4.1 Regression] SEGV in is_gimple_variable during loop-ivopts
while building Ada RTS
cxa4006 and cxa4017 fail the same way (STORAGE_ERROR) as vms_conv.adb.
See the email I
:
gcc/testsuite/gcc.dg: 20050702-1.c
gcc/testsuite/gcc.dg/tree-ssa: pr14490-1.c pr14490-2.c
pr14490-3.c pr14490-4.c
Log message:
2005-07-02 Andrew Pinski [EMAIL PROTECTED]
PR middle-end/14490
* fold-const.c
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-02
16:25 ---
Fixed.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
--
Bug 19987 depends on bug 14490, which changed state.
Bug 14490 Summary: [tree-ssa] Simplify a - 10 150 into a 160
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14490
What|Old Value |New Value
.ident GCC: (GNU) 4.1.0 20050702 (experimental)
.section.note.GNU-stack,,@progbits
---
--
Summary: gcc -O2 discards cast to volatile
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-02
16:48 ---
See PR 21568 and http://gcc.gnu.org/ml/gcc/2005-05/msg00085.html.
This is allowed by the C and C++ standards.
*** This bug has been marked as a duplicate of 21568 ***
--
What|Removed
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-02
16:48 ---
*** Bug 22278 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
On various platforms, the libstdc++ testsuite fails early with an ICE building
testsuite_abi.cc. This includes at least hppa64-hpux and ia64-hpux (compilers
as of 20050702 07:00 UTC) and gcc-testresults shows it on x86_64-linux; it
didn't happen with 20050630 compilers. The dates show
--
What|Removed |Added
CC||dberlin at gcc dot gnu dot
||org
Keywords|
--- Additional Comments From olivier dot baudron at m4x dot org 2005-07-02
16:59 ---
I am not sure this is the same problem.
Besides, the following code is *not* optimized away with -O2:
void test (volatile char *addr) {
*addr;
}
--
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-02
17:01 ---
Looks like it only effects 64bit targets:
http://gcc.gnu.org/ml/gcc-testresults/2005-07/msg00058.html
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-02
17:03 ---
Did you read the message which I referenced? it is still not a bug if you read
the message.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22278
--
What|Removed |Added
Target Milestone|--- |4.1.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22276
--
What|Removed |Added
CC||dberlin at gcc dot gnu dot
||org, pinskia at gcc dot gnu
--
What|Removed |Added
Component|ada |tree-optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22277
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-02
17:17 ---
Are you building in the source directory?
if so can you try building in an object directory like the instation directions
recomend?
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-02
17:18 ---
Patch here but you forgot the changeLog :).
--
What|Removed |Added
URL|
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-02
17:22 ---
Are you sure that your tree-ssa-alias.c is not modified?
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-02
17:23 ---
Most likely related to PR 22279.
--
What|Removed |Added
BugsThisDependsOn|
--
What|Removed |Added
OtherBugsDependingO||22277
nThis||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22279
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-02
17:26 ---
Confirmed.
--
What|Removed |Added
URL|http://gcc.gnu.org/ml/gcc- |
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-02
17:32 ---
Never mind, this is comming from flex.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-02
17:32 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
--- Additional Comments From falk at debian dot org 2005-07-02 17:33
---
I see a difference here in that gcc doesn't know whether the referenced
object is declared to be volatile, it isn't visible as in PR 21568.
IMHO we actually have a bug here; I don't see anything in the standard
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-02
17:42 ---
Since the orginal pointer is not violatile the cast will not change any thing
since the compiler can
deduce it is not violatile.
From C99, 5.1.2.3 P3:
In the abstract machine, all expressions are
--- Additional Comments From falk at debian dot org 2005-07-02 17:53
---
(In reply to comment #5)
Since the orginal pointer is not violatile the cast will not change any thing
since the compiler can
deduce it is not violatile.
It could deduce that if it was invalid to form a
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-02
18:32 ---
Here is a patch fixes the problem:
Index: tree-cfg.c
===
RCS file: /cvs/gcc/gcc/gcc/tree-cfg.c,v
retrieving revision 2.207
diff -u -p -r2.207
--- Additional Comments From giovannibajo at libero dot it 2005-07-02
19:10 ---
Can we get a preprocessed/reduced source?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22279
This was introduced by:
2005-06-29 Daniel Berlin [EMAIL PROTECTED]
* tree-complex.c (complex_variable_components): Now a hashtable.
(cvc_lookup): Ditto.
(cvc_insert): Ditto.
(create_components): Use referenced var iterator.
Initialize hashtable.
--
What|Removed |Added
CC||dberlin at gcc dot gnu dot
||org
Target Milestone|---
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-07-02
19:28 ---
We can't iterate in sequence anymore.
i'll fix this.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22280
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-07-02
19:34 ---
We can't iterate in sequence anymore.
i'll fix this.
--
What|Removed |Added
The following program returns 1 instead of 0 because gcc seems not to do a
static_cast followed by a const_cast when doing the C-style cast. This is in
violation of 5.4 of the standard.
The problem first appeared in gcc 4.0.0. Here is the -v output of the version I
am currently using:
Target:
--
What|Removed |Added
CC||mmitchel at gcc dot gnu dot
||org
Keywords|
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-02
19:55 ---
This looks like basicially PR 22132 but this has a short testcase.
--
What|Removed |Added
--
What|Removed |Added
BugsThisDependsOn||22281
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22132
See:
http://gcc.gnu.org/onlinedocs/gcc-3.4.4/g77/Loc-Intrinsic.html
--
Summary: loc intrinsic is not implemented in gfortran
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P2
Component:
--
What|Removed |Added
OtherBugsDependingO||19292
nThis||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22282
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-02
20:45 ---
Patch here: http://gcc.gnu.org/ml/gcc-patches/2005-07/msg00102.html.
I can confirm that it fixes the ICE too.
--
What|Removed |Added
--- Additional Comments From gcc2eran at tromer dot org 2005-07-02 22:07
---
Prior versions of gcc did respect casts to pointer-to-volatile and did not
optimize away the access. I've seen a lot of code that relies on that, and which
would thus be broken by gcc 4.x (in a subtle and
pinskia at gcc dot gnu dot org [EMAIL PROTECTED] writes:
| See PR 21568 and http://gcc.gnu.org/ml/gcc/2005-05/msg00085.html.
Both those issues about completely *different* from the issue
submitted in this PR. In the above cases, the accessed object actually
is NOT volatile. This is not the
--- Additional Comments From gdr at integrable-solutions dot net
2005-07-02 22:08 ---
Subject: Re: gcc -O2 discards cast to volatile
pinskia at gcc dot gnu dot org [EMAIL PROTECTED] writes:
| See PR 21568 and http://gcc.gnu.org/ml/gcc/2005-05/msg00085.html.
Both those issues about
--- Additional Comments From gdr at integrable-solutions dot net
2005-07-02 22:10 ---
Subject: Re: gcc -O2 discards cast to volatile
pinskia at gcc dot gnu dot org [EMAIL PROTECTED] writes:
| Did you read the message which I referenced?
Not just because people disagrees with your
--- Additional Comments From gdr at integrable-solutions dot net
2005-07-02 22:10 ---
Subject: Re: gcc -O2 discards cast to volatile
falk at debian dot org [EMAIL PROTECTED] writes:
| I see a difference here in that gcc doesn't know whether the referenced
| object is declared to be
--- Additional Comments From gdr at integrable-solutions dot net
2005-07-02 22:11 ---
Subject: Re: gcc -O2 discards cast to volatile
pinskia at gcc dot gnu dot org [EMAIL PROTECTED] writes:
| Since the orginal pointer is not violatile
How do you know that? Just looking at function
--- Additional Comments From gdr at integrable-solutions dot net
2005-07-02 22:12 ---
Subject: Re: gcc -O2 discards cast to volatile
falk at debian dot org [EMAIL PROTECTED] writes:
| According to Joseph Myers, the question is whether this counts as access to
| a volatile object,
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-07-02
22:18 ---
Subject: Bug 22280
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-07-02 22:18:24
Modified files:
gcc: ChangeLog tree-sra.c
Log message:
--- Additional Comments From falk at debian dot org 2005-07-02 22:19
---
(In reply to comment #8)
I can't imagine a programmer casting into a pointer to volatile without really
meaning it, so if the behavior is not defined by the standard then both
compatibility and the principle of
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-02
22:20 ---
(In reply to comment #13)
It is also wrong-code.
This is the opposite view of what JSM said on IRC. Take it up with him if you
believe otherwise.
Basically this is all implemention defined and since
--- Additional Comments From gdr at integrable-solutions dot net
2005-07-02 22:20 ---
Subject: Re: gcc -O2 discards cast to volatile
gcc2eran at tromer dot org [EMAIL PROTECTED] writes:
| Prior versions of gcc did respect casts to pointer-to-volatile and did not
| optimize away the
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-02
22:26 ---
Fixed.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
--- Additional Comments From gdr at integrable-solutions dot net
2005-07-02 22:39 ---
Subject: Re: gcc -O2 discards cast to volatile
pinskia at gcc dot gnu dot org [EMAIL PROTECTED] writes:
| (In reply to comment #13)
|
| It is also wrong-code.
|
| This is the opposite view of
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-02
22:49 ---
For all useful purposes, it helps remembering that GCC is not an
academic exercise in C standard reading.
Ok, then all of your comments about extensions to C++ should be thrown out the
window since I
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-07-02
23:06 ---
Subject: Bug 21742
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-07-02 23:06:43
Modified files:
gcc: ChangeLog expr.c
Log message:
--- Additional Comments From gcc2eran at tromer dot org 2005-07-02 23:30
---
(In reply to comment #17)
Furthermore, the fundamental issue is whether this
*(volatile int*) (int*) (foo);
(or equivalent) where foo has been defined volatile int should be
treated differently from
--- Additional Comments From falk at debian dot org 2005-07-02 23:45
---
(In reply to comment #19)
How about this?
int foo;
*(volatile int*) (foo);
In other words, why should the compiler bother at all with the qualifiers of
what the pointer really points to?
Because
--- Additional Comments From gdr at integrable-solutions dot net
2005-07-02 23:54 ---
Subject: Re: gcc -O2 discards cast to volatile
pinskia at gcc dot gnu dot org [EMAIL PROTECTED] writes:
| For all useful purposes, it helps remembering that GCC is not an
| academic exercise in C
gcc2eran at tromer dot org [EMAIL PROTECTED] writes:
| --- Additional Comments From gcc2eran at tromer dot org 2005-07-02 23:30
---
| (In reply to comment #17)
| Furthermore, the fundamental issue is whether this
|
| *(volatile int*) (int*) (foo);
|
| (or equivalent) where foo
--- Additional Comments From gdr at integrable-solutions dot net
2005-07-03 00:03 ---
Subject: Re: gcc -O2 discards cast to volatile
gcc2eran at tromer dot org [EMAIL PROTECTED] writes:
| --- Additional Comments From gcc2eran at tromer dot org 2005-07-02 23:30
---
| (In
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-07-03
01:15 ---
Subject: Bug 18279
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-07-03 01:15:01
Modified files:
gcc: ChangeLog c-decl.c tree-dump.c
Log
--- Additional Comments From gcc2eran at tromer dot org 2005-07-03 01:19
---
(In reply to comment #22)
| int foo;
| *(volatile int*) (foo);
It was included in my previous message.
Then it's still eluding me, since your foo (the object?) was volatile.
| In other words,
--- Additional Comments From joseph at codesourcery dot com 2005-07-03
01:27 ---
Subject: Re: gcc -O2 discards cast to volatile
On Sun, 3 Jul 2005, gcc2eran at tromer dot org wrote:
Of course, but please forgive my ignorance -- where does does the standard
prescribe these
--- Additional Comments From gdr at integrable-solutions dot net
2005-07-03 01:42 ---
Subject: Re: gcc -O2 discards cast to volatile
gcc2eran at tromer dot org [EMAIL PROTECTED] writes:
| but that is a fundamental departure from the language semantics.
| Replace volatile with const
--- Additional Comments From gdr at integrable-solutions dot net
2005-07-03 01:43 ---
Subject: Re: gcc -O2 discards cast to volatile
gcc2eran at tromer dot org [EMAIL PROTECTED] writes:
| (In reply to comment #22)
| | int foo;
| | *(volatile int*) (foo);
|
| It was
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-07-03
01:46 ---
Subject: Bug 20842
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-07-03 01:46:12
Modified files:
gcc/fortran: ChangeLog io.c
--- Additional Comments From gcc2eran at tromer dot org 2005-07-03 01:46
---
(In reply to comment #24)
Thanks!
None of the quotes and references in comment 23 changed in N1124.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22278
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot
|dot org |org
Status|NEW
--- Additional Comments From hugh at mimosa dot com 2005-07-03 01:53
---
[ see https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=162274 ]
I feel that he gcc documentation promises that there will be an access. The
documentation can change, but it is a contract between the
--- Additional Comments From gcc2eran at tromer dot org 2005-07-03 02:30
---
(In reply to comment #25)
If when the compiler sees const T* p, it assumes that *p is
effectively const, then it would miscompile
int foo(int* p, const int* q) {
int r = *q;
*p = r * r;
--- Additional Comments From gdr at integrable-solutions dot net
2005-07-03 02:54 ---
Subject: Re: gcc -O2 discards cast to volatile
gcc2eran at tromer dot org [EMAIL PROTECTED] writes:
| [#5] If an attempt is made to modify an object defined with
| a
--- Additional Comments From gcc2eran at tromer dot org 2005-07-03 04:14
---
(In reply to comment #30)
| OK. Then the volatile-stripping direction can be handled arbitrarily.
I do not understand that comment.
I meant that we were mostly concerned about what the standard says about
gcc2eran at tromer dot org [EMAIL PROTECTED] writes:
| (In reply to comment #30)
| | OK. Then the volatile-stripping direction can be handled arbitrarily.
|
| I do not understand that comment.
|
| I meant that we were mostly concerned about what the standard says about the
| effect of
--- Additional Comments From gdr at integrable-solutions dot net
2005-07-03 04:43 ---
Subject: Re: gcc -O2 discards cast to volatile
gcc2eran at tromer dot org [EMAIL PROTECTED] writes:
| (In reply to comment #30)
| | OK. Then the volatile-stripping direction can be handled
--- Additional Comments From gdr at integrable-solutions dot net
2005-07-03 05:18 ---
Subject: Re: gcc -O2 discards cast to volatile
gcc2eran at tromer dot org [EMAIL PROTECTED] writes:
| --- Additional Comments From gcc2eran at tromer dot org 2005-07-03 05:09
---
| (In
I use zh_TW.UTF-8 as the default encoding in my machine, and I found that I
failed to build libjava. The error messsages are as following:
(LC_ALL=zh_TW.UTF-8 make)
make[2]: Entering directory `/home/jserv/build-gcj/i686-pc-linux-gnu/libjava'
/bin/sh ./libtool --mode=compile
--- Additional Comments From hugh at mimosa dot com 2005-07-03 05:40
---
Simple rule about const and volatile qualifiers (not restrict): the program can
manipulate pointer values with and without their qualifiers. But when the
program accesses an object that is a volatile object (i.e.
--- Additional Comments From jserv at kaffe dot org 2005-07-03 05:19
---
Created an attachment (id=9196)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9196action=view)
Fix the incorrect input filenames in the Makefile of libjava
--
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-03
05:52 ---
*outside = avail;
Because at this point avail is known not to volatile. Did you read what was
writting in comment #1 and
#4?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21568
--- Additional Comments From gcc2eran at tromer dot org 2005-07-03 04:55
---
Why was this bug closed? The testcases in comment 5 do *not* pass.
Here's the first testcase, fixed to compile cleanly:
int avail;
int main() {
volatile int **outside = (volatile
91 matches
Mail list logo
