This is for "gcc version 4.3.0 (GCC)"
This is very likely related to 35729 and 35762.
This code:
extern int bar (void);
volatile int g_156;
int foo (void)
{
if (bar ())
return 0;
else
return g_156;
}
Compiled with:
gcc -O1 -S foo.c
Gives:
foo:
pushl %ebp
movl
--- Comment #2 from zlynx at acm dot org 2008-03-30 03:46 ---
Created an attachment (id=15399)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15399&action=view)
test program, build: g++ timer-test.cc -lrt
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35763
--- Comment #1 from zlynx at acm dot org 2008-03-30 03:43 ---
Forgot to mention, I filed a bug for fwrite too:
http://sources.redhat.com/bugzilla/show_bug.cgi?id=5998
Until they fix that (if they do) it will be useless to check fwrite's return
value since you can't know how many bytes w
I noticed this when running a program that uses a periodic timer signal. The
sigaction did not set SA_RESTART. During program runs, huge chunks of console
output would disappear.
I sort of tracked this down to the code in libstdc++ that uses fwrite to do the
output of cout and cerr. That is a b
This is for "gcc version 4.3.0 (GCC)"
This is similar to bug 35729. I'm filing a new report since the behavior seems
to be a different one.
This code:
volatile short g_10 = 0;
volatile int g_13 = 0;
int func_1 (void)
{
for (g_10 = 0; g_10 > 10; g_10++)
return g_13;
return 0;
}
When co
--- Comment #1 from bugzilla-gcc at thewrittenword dot com 2008-03-30
02:24 ---
Created an attachment (id=15398)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15398&action=view)
Patch for a generated file
This patch allowed the build to complete for us, unfortunately Makefile.in
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-03-30 00:57 ---
This is a predict_expr tree. Shouldn't TREE_SIDE_EFFECTS be set on that
expression?
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-03-30 00:52 ---
Confirmed, only happens with the C++ front-end.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-03-30 00:50 ---
So this was introduced by the gimplify_modify_expr changes. The C++ front-end
actually produces error_mark_node for the call, maybe the C front-end should do
the same.
--
http://gcc.gnu.org/bugzilla/show_bug.cg
--- Comment #3 from reichelt at gcc dot gnu dot org 2008-03-30 00:42
---
Fixed on mainline by Douglas' patch:
2008-03-25 Douglas Gregor <[EMAIL PROTECTED]>
* typeck.c (composite_pointer_type_r): Add SFINAE support.
...
--
reichelt at gcc dot gnu dot org changed:
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-03-30 00:32 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-03-30 00:30 ---
Complex lowering is creating phi's with constant arguments on abnormal edges.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35737
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-03-30 00:24 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC|
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-03-30 00:20 ---
This is most likely because there is no way to mangle fixed point types at all.
So really I don't think this should be a P2 or marked as a regression until
the ABI has been finialized
--
http://gcc.gnu.org/bugz
--- Comment #1 from burnus at gcc dot gnu dot org 2008-03-29 23:23 ---
Confirm.
The algorithm below does essentially:
while (1,0,1,0,1)
uda1l( 1 _ 3 _ 5) = 2 3 4 5 6
else
udal1 ( _ 3 _ 5 _) = 6 5 4 3 2
done
That is
1. uda1l(1) = 2
2. uda1l(3) = 5 <---\__
3. uda1l(3) = 4 <---/
4. u
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-03-29 23:17 ---
It certainly is not setting __cplusplus if you are not using C++. Other than
that this is not a useful bugreport.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35761
--- Comment #1 from devilsclaw at devilsclaws dot net 2008-03-29 23:01
---
I also tried -O0 , -O1 , -O3 and -O4. The only one that worked as you would
guess was -O0.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35761
I'm currently compiling my linux based of the Linux From Scratch SVN.
I decided to try my hand at compiling with the gcc 4.3.0.
The current bug im noticing has to do with the -O2 flag and __cplusplus.
I have done a search through the bug database all most errors that I have seen
have had __cplus
--- Comment #6 from pcarlini at suse dot de 2008-03-29 22:43 ---
Fixed.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #5 from paolo at gcc dot gnu dot org 2008-03-29 22:39 ---
Subject: Bug 35725
Author: paolo
Date: Sat Mar 29 22:38:36 2008
New Revision: 133722
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133722
Log:
2008-03-29 Paolo Carlini <[EMAIL PROTECTED]>
PR libstd
--- Comment #4 from paolo at gcc dot gnu dot org 2008-03-29 22:38 ---
Subject: Bug 35725
Author: paolo
Date: Sat Mar 29 22:38:19 2008
New Revision: 133721
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133721
Log:
2008-03-29 Paolo Carlini <[EMAIL PROTECTED]>
PR libstd
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35760
While going to look into fixing PR 35314, I found this bug for PowerPC darwin.
A simple testcase:
int foo()
{
__complex__ float i = 0;
}
Will ICE in memory_address when we don't compile with PIC turned on.
t.c: In function 'foo':
t.c:3: internal compiler error: in memory_address, at explow.c:492
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2008-03-29 21:19
---
I have submitted glibc PR
http://sources.redhat.com/bugzilla/show_bug.cgi?id=5997
With a C test case that clearly shows the problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34128
--- Comment #2 from hjl dot tools at gmail dot com 2008-03-29 21:12 ---
A patch is posted at
http://gcc.gnu.org/ml/gcc-patches/2008-03/msg01848.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
---
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-03-29 21:04 ---
This is caused by PHI-opt, fixing.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
The following program computes the wrong result for a WHERE where
different sections of the same array are in both the WHERE and
ELSEWHERE section. It's "as if" the ELSEWHERE block were
ignored.
Dick Hendrickson
program RG0023
! fails on Windows XP
! gcc version 4.4.0 20080312 (experimenta
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-03-29 21:01 ---
We have invalid gimple before PRE:
k_7 = COMPLEX_EXPR <(int) D.1197_2, 0>;
Which we don't catch.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from reichelt at gcc dot gnu dot org 2008-03-29 20:18
---
Testing a patch.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Assigne
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-03-29 20:17 ---
This is caused by the extra type checking which Richard Guenther added.
It is not just _Decimal128, but almost all types which are broken.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-03-29 19:44 ---
This is the patch which I am testing:
Index: cp/typeck.c
===
--- cp/typeck.c (revision 133711)
+++ cp/typeck.c (working copy)
@@ -3917,6 +3917,10 @@ cp_
--- Comment #5 from regehr at cs dot utah dot edu 2008-03-29 19:32 ---
Subject: Re: apparent integer math bug
> wrapping behavior with signed types. Note the C standard is over 18
> years old now so I had hoped people would still not making the mistake
> of thinking signed interger
--- Comment #4 from pinskia at gmail dot com 2008-03-29 19:27 ---
Subject: Re: apparent integer math bug
Sent from my iPhone
On Mar 29, 2008, at 12:16, "regehr at cs dot utah dot edu"
<[EMAIL PROTECTED]
> wrote:
>
>
> --- Comment #3 from regehr at cs dot utah dot edu 2008-03
Sent from my iPhone
On Mar 29, 2008, at 12:16, "regehr at cs dot utah dot edu" <[EMAIL PROTECTED]
> wrote:
--- Comment #3 from regehr at cs dot utah dot edu 2008-03-29
19:16 ---
Subject: Re: apparent integer math bug
This multiplication overflows so the resulting behavior i
--- Comment #3 from regehr at cs dot utah dot edu 2008-03-29 19:16 ---
Subject: Re: apparent integer math bug
> This multiplication overflows so the resulting behavior is undefined.
Right-- but always in the past it has been (or seemed) fine to assume
two's complement overflow behavi
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-03-29 19:14 ---
Created an attachment (id=15397)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15397&action=view)
Patch which should fix it
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30186
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-03-29 18:55 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-03-29 18:49 ---
It worked with "4.3.0 20070623" and "4.2.0 20061019".
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35758
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-03-29 18:47 ---
This is related to PR 27433 and I bet fixing this one will also fix that one.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35758
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-03-29 18:46 ---
This blocks me from even thinking about updating the PS3 toolchain to 4.3.0.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35758
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-03-29 18:45 ---
This is caused by the delaying of vector_size attribute inside templates.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
The following testcase used to work in 4.1.1 but no longer does:
#define vector __attribute__((vector_size(16) ))
template
vector signed int MyFunction(vector float value) {}
template
void MyFunction(float ){}
int main()
{
vector float myVector;
float myFloat;
MyFunction<1>(myVector
--- Comment #2 from reichelt at gcc dot gnu dot org 2008-03-29 17:57
---
Testing a patch.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Assigne
--- Comment #1 from reichelt at gcc dot gnu dot org 2008-03-29 17:43
---
Confiremd. This happens since GCC 4.2.0.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #7 from reichelt at gcc dot gnu dot org 2008-03-29 17:32
---
It's a duplicate of PR24602.
*** This bug has been marked as a duplicate of 24602 ***
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #11 from reichelt at gcc dot gnu dot org 2008-03-29 17:32
---
*** Bug 35596 has been marked as a duplicate of this bug. ***
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from reichelt at gcc dot gnu dot org 2008-03-29 17:11
---
Here's a reduced testcase:
=
template struct A
{
friend void foo(const A&)
{
__FUNCTION__;
}
};
inline void foo(const A<0>&)
{
__FUNCTION__;
}
void bar()
{
foo(A
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-03-29 16:57 ---
... (rerun 16) ...
this means the 16th invocation failed. This is just regular mudflap noise.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35755
--- Comment #1 from hjl dot tools at gmail dot com 2008-03-29 16:09 ---
It is introduced by revision 132518.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
sse.md has
(define_insn "sse4_1_blendp"
[(set (match_operand:SSEMODEF2P 0 "register_operand" "=x")
(vec_merge:SSEMODEF2P
(match_operand:SSEMODEF2P 2 "nonimmediate_operand" "xm")
(match_operand:SSEMODEF2P 1 "register_operand" "0")
(match_operand:SI 3 "const_0
--- Comment #1 from burnus at gcc dot gnu dot org 2008-03-29 15:52 ---
Confirm. See also PR 35745.
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from burnus at gcc dot gnu dot org 2008-03-29 15:52 ---
See also PR 35756.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35745
The following program computes the wrong values for the even
(elsewhere branch) of the left hand array. It looks like the
function R_MY_MIN_I is evaluated before the store in the WHERE
branch happens.
The same thing happens if the R_M* functions are external
rather than contained.
Dick Hendrick
On Fedora 8/Intel64, gcc 4.4 revision 133638 gave
FAIL: libmudflap.cth/pass39-frag.c (-O2) (rerun 16) execution test
FAIL: libmudflap.cth/pass39-frag.c (-O2) (rerun 16) output pattern test
Revision 133612 is OK. It could be related to stack limit.
--
Summary: [4.4 Regression]: libmu
--- Comment #7 from jason at gcc dot gnu dot org 2008-03-29 15:19 ---
The bug is that the temporary object created by the C99 compound literal syntax
doesn't have proper C++ temporary lifetime; the compiler treats it as living
until the end of the block, so the goto seems to be skipping
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org
|dot org
The comma after the "P" is optional in Fortran 2003 if followed by a repeat
specifier but required in Fortran 95. (According to MR&C)
--
Summary: -std=f95: Reject "1P2E12.4" w/o a comma after the "P"
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
--- Comment #3 from hutchinsonandy at aim dot com 2008-03-29 12:55 ---
Created an attachment (id=15396)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15396&action=view)
Patch to correct return_address
The attached patch fixes this problem and PR21078
The AVR target support for bui
--- Comment #1 from hutchinsonandy at aim dot com 2008-03-29 11:37 ---
Created an attachment (id=15395)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15395&action=view)
Setjmp patch for AVR
The attached patch is a fix for AVR target. MIPS does something similar to get
around same
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-03-29 10:56 ---
Jason, can you have a look here?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-03-29 10:52 ---
Here's a shorter testcase:
struct object { int one_o; int allocstamp; };
int pgci_pointable (object obj);
void foo(void);
int main (int argc, char *argv[])
{
if (pgci_pointable((object){7,100}))
{
bad_re
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-03-29 10:27 ---
use unsigned arithmetic.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pinskia at gmail dot com 2008-03-29 09:02 ---
Subject: Re: postreload can handle the case where the memory locations use
different modes
I forgot to mention that the dse patch fixes the problem earlier on so
we now do the optimization pre-reload. We still have an
I forgot to mention that the dse patch fixes the problem earlier on so
we now do the optimization pre-reload. We still have an extra store
but that is recorded as another bug I filed.
Sent from my iPhone
On Mar 29, 2008, at 1:55, "pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]
> wrote:
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-03-29 08:55 ---
Hmm, I wonder how important this is now after the DSE patch for PR 33927 which
basically does the same thing and it also runs after reload. I really don't
want to make cselib any slower than it is already and post r
--- Comment #8 from pault at gcc dot gnu dot org 2008-03-29 08:23 ---
(In reply to comment #7)
> I have a regtested patch for this but cannot post it until Saturday, when I am
> back from vacation.
>
> Paul
This has been delayed by the discovery of memory leaks in a number of the
gfort
--- Comment #7 from pault at gcc dot gnu dot org 2008-03-29 08:20 ---
Fixed on trunk and 4.3
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from pault at gcc dot gnu dot org 2008-03-29 08:19 ---
Fixed on trunk and 4.3
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from pault at gcc dot gnu dot org 2008-03-29 08:18 ---
Subject: Bug 35702
Author: pault
Date: Sat Mar 29 08:17:36 2008
New Revision: 133711
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133711
Log:
2008-03-29 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #6 from pault at gcc dot gnu dot org 2008-03-29 08:18 ---
Subject: Bug 35698
Author: pault
Date: Sat Mar 29 08:17:36 2008
New Revision: 133711
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133711
Log:
2008-03-29 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #5 from pault at gcc dot gnu dot org 2008-03-29 08:11 ---
Subject: Bug 35702
Author: pault
Date: Sat Mar 29 08:11:02 2008
New Revision: 133710
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133710
Log:
2008-03-29 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #5 from pault at gcc dot gnu dot org 2008-03-29 08:11 ---
Subject: Bug 35698
Author: pault
Date: Sat Mar 29 08:11:02 2008
New Revision: 133710
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133710
Log:
2008-03-29 Paul Thomas <[EMAIL PROTECTED]>
PR fortran/
--- Comment #3 from pault at gcc dot gnu dot org 2008-03-29 07:27 ---
(In reply to comment #2)
Hah! It's still worse than I thought. Not only is a temporary not made but
the scalarizer is being blown out of the water by the likes of:
program main
implicit none
complex, dimension(2
73 matches
Mail list logo
