--- Additional Comments From mmitchel at gcc dot gnu dot org 2004-10-12 06:46
---
The bug here is that we are checking complain at all.
SFINAE does not say that when given a set of overload candidates you perform
type deduction and then discard any candiates for which an any error
--- Additional Comments From anlauf at hep dot tu-darmstadt dot de 2004-10-12
06:55 ---
(In reply to comment #4)
Subject: Re: Math error in simple divide operation
I suppose then that a warning would be good when mixing precisions in
assignments.
With Fortran 77, the great free
--- Additional Comments From micis at gmx dot de 2004-10-12 07:25 ---
Whith the patch http://gcc.gnu.org/ml/gcc-patches/2004-10/msg00853.html
applied I get a new ICE when I compile ACE542:
/usr/local/gcc40/bin/g++40 -W -Wall -Wpointer-arith -fpermissive -O2 -
D_REENTRANT
Building the head ( 20041011 checkout ) resulted in a lot of warnings regarding
unknown predicates during genrecog.
Part of the log showing the warning messages is inlined below:
build/genrecog /uselater/fsf/sources/gcc-head/gcc/gcc/config/arc/arc.md
tmp-recog.c
--- Additional Comments From pcarlini at suse dot de 2004-10-12 08:27 ---
However, please give me a bit to finish this stuff up! I'll check in a
fix for this immediate problem, and then please give me a bit of time to
do a round of performance analysis. I'll ping you when I'm done,
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-10-12 08:32
---
Subject: Bug 17301
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2004-10-12 08:32:17
Modified files:
gcc: ChangeLog c-typeck.c
I build gcc40 with patches for bug16882 and bug17724 (newest patch
http://gcc.gnu.org/ml/gcc-patches/2004-10/msg00853.html)
applied I get a new ICE when I compile ACE542:
/usr/local/gcc40/bin/g++40 -W -Wall -Wpointer-arith -fpermissive -O2 -
D_REENTRANT -DACE_HAS_AIO_CALLS -D_GNU_SOURCE
--- Additional Comments From micis at gmx dot de 2004-10-12 08:37 ---
Created an attachment (id=7329)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7329action=view)
set of source files
command line:
g++40 -fpermissive -O2 -D_REENTRANT -DACE_HAS_AIO_CALLS -D_GNU_SOURCE
--- Additional Comments From giovannibajo at libero dot it 2004-10-12 08:45
---
If it cannot be reproduced with --save-temps, it is probably a memory
corruption or something. I think we should do one thing at a time: once Jakub's
patch is in, we will look into the following problem.
--- Additional Comments From micis at gmx dot de 2004-10-12 08:48 ---
I tried to copy all needed files in a directory and while this file set was
still not complete I got a segmentation fault when I tried to compile.
I filed a bug report bug17944
Michael Cieslinski
--
--- Additional Comments From pcarlini at suse dot de 2004-10-12 08:53 ---
Sorry, actually I meant around 25%, rather troublesome, anyway... Frankly,
I don't know where the slowdown comes from, we should profile the testcase for
both the allocators. These are some numbers on my P4-2400:
The collect2 tool which comes with gcc outputs the help page generated when
the --help option is specified to standard error output rather than standard
output. This makes it impossible to browse the help with collect2 --help |
more. It also contravenes the GNU coding standards:
--- Additional Comments From gdr at cs dot tamu dot edu 2004-10-12 09:55 ---
Subject: Re: [3.4/4.0 regression] local classes as template argument
mmitchel at gcc dot gnu dot org [EMAIL PROTECTED] writes:
| The bug here is that we are checking complain at all.
|
| SFINAE does not say
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-10-12 10:13
---
Subject: Bug 17903
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2004-10-12 10:13:39
Modified files:
libjava: ChangeLog
Added files:
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |nathan at gcc dot gnu dot
|dot org |org
Status|NEW
--- Additional Comments From nathan at gcc dot gnu dot org 2004-10-12 10:34
---
I think this is an artifact of the design of the current value range
propagation. That's not really range propagation by comparison result CSEing.
The loop exit is i 10, and the next comparison is i ==
--- Additional Comments From nathan at gcc dot gnu dot org 2004-10-12 10:38
---
It occurs to me that converting to (when safe) is a lose on targets that
do not have setcond instructions.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17107
--- Additional Comments From micis at gmx dot de 2004-10-12 11:12 ---
With a complete set of files this ICE doesn't occur.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17944
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-12 11:42
---
Fixed.
--
What|Removed |Added
Status|NEW |RESOLVED
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-12 11:43
---
Confirmed, this is a target problem, the warnings are correct.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-12 11:44
---
Patch here: http://gcc.gnu.org/ml/gcc-patches/2004-10/msg00968.html.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-12 11:50
---
Collect2 just passes --help to ld so it is an binutils bug.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-12 11:54
---
Was it before or after the fix for PR 17826?
--
What|Removed |Added
--- Additional Comments From ramana dot radhakrishnan at codito dot com
2004-10-12 12:33 ---
All these would be due to non-use of the define_predicate md file construct. The
backend needs to be cleaned to use the new define_predicate construct.
--
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-12 12:48
---
Lets close this as fixed as it is confusing to leave this bug open as the ICE has been
fixed and QOI
problem is PR 17011.
--
What|Removed |Added
--
Bug 17011 depends on bug 16929, which changed state.
Bug 16929 Summary: [3.4/4.0 Regression] ICE on taking address of member in default
parameter to member function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16929
What|Old Value |New Value
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-12 12:56
---
Fixed by the same patch which fixed PR 17657.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-12 13:03
---
Can you try this again?
--
What|Removed |Added
Status|NEW
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-12 13:10
---
Fixed by:
* fold-const.c (fold_build_cleanup_point_expr): New function.
* tree.h (fold_build_cleanup_point_expr): Prototype.
cp/ChangeLog:
* semantics.c (maybe_cleanup_point_expr):
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-12 13:25
---
Now on the mainline (with checking still enabled) we get a MAX of 328M of GC memory
allocated and
then go down to 189M. This is better but it can be improved still.
--
What|Removed
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-12 13:28
---
Also this memory usage was in the front-end before optimizations.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-12 13:29
---
Never mind, I was looking at the wrong thing, it was after the parser was done.
--
What|Removed |Added
--- Additional Comments From kazu at cs dot umass dot edu 2004-10-12 14:11 ---
A patch posted at:
http://gcc.gnu.org/ml/gcc-patches/2004-10/msg00986.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17931
People sometimes code a MASK when they intended a MASK.
It would be good if gcc issued a warning for suspect cases.
--
Summary: wanted: warning for a MASK when a MASK was
probably intended
Product: gcc
Version: 4.0.0
Status:
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-12 14:19
---
I the only way this can be done right is not to warn about a 1 as people sometimes
do that
(especially with macros) and that shows up in GCC a huge amount.
--
What|Removed
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-12 14:27
---
Really we should not warn because we could be doing a CONST where we want CONST to
be
compared against 0 so this is invalid.
--
What|Removed |Added
--- Additional Comments From trt at acm dot org 2004-10-12 14:45 ---
Patch here: http://gcc.gnu.org/ml/gcc-patches/2004-10/msg00990.html
This patch does not warn about a 1 for the reason noted in comment #1.
Some mistakes will go unwarned, but it still catches quite a lot.
The
///
struct Foo
{
operator int() __attribute__((deprecated));
};
int main()
{
Foo f;
(int)f;
}
///
gives:
warning: `operator 1' is deprecated
In real code the '1' is often a bigger number.
--
Summary: bad warning with
--- Additional Comments From mueller at kde dot org 2004-10-12 15:41 ---
Please reopen this bugreport, its not a duplicate of 17554 and
still unfixed (while 17554 is fixed).
--
What|Removed |Added
--- Additional Comments From mueller at kde dot org 2004-10-12 15:42 ---
reduced testcase:
struct C
{
int *c;
C () : c (0) { }
C (const C x) : c (x.c) { }
C operator++ () { return *this; }
};
void breakme (void)
{
C j;
bool k = false;
for (;; k ? j : ++j)
--- Additional Comments From bkoz at gcc dot gnu dot org 2004-10-12 15:50 ---
Yep I'll add this to my other tests (insert-thread) to profile today, thanks
for the pointer.
Can I close this out? I believe this is fixed, no?
-benjamin
--
--- Additional Comments From pcarlini at suse dot de 2004-10-12 15:54 ---
Yes, can only be ok, now! ;)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17937
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-12 16:00
---
Hmm, i will look into it.
--
What|Removed |Added
Status|RESOLVED
--- Additional Comments From pluto at pld-linux dot org 2004-10-12 16:03 ---
Created an attachment (id=7330)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7330action=view)
testcase #2
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17942
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-12 16:04
---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-12 16:06
---
Actually here is the reduced testcase:
struct C
{
C (const C x);
};
C f();
void breakme (C j, bool k)
{
for (;; k ? j : f()) ;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17661
--- Additional Comments From micis at gmx dot de 2004-10-12 16:07 ---
I will check this tomorrow.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17944
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-12 16:07
---
Confirmed, I thought I saw a bug like this before.
--
What|Removed |Added
--- Additional Comments From bangerth at dealii dot org 2004-10-12 16:07 ---
If this is put under a flag of its own, it may actually be useful. I
see no reason why we should dismiss it that quickly.
W.
--
What|Removed |Added
--- Additional Comments From pluto at pld-linux dot org 2004-10-12 16:09 ---
I found the second bug and I think it's related to the first report.
/ -O0 on all tests /
With -march={i[3456]86,athlon} gcc works fine.
With -march=pentium[34] gcc fails:
In file included from
--- Additional Comments From mmitchel at gcc dot gnu dot org 2004-10-12 16:13
---
As in the discussion of DR 415, it's not feasible to postpone all error messages
until overload resolution has succeeded. The example in DR 415 is that you
might need to instantiate a class type to do
--- Additional Comments From bangerth at dealii dot org 2004-10-12 16:14 ---
Yes, me too. What a funny message :-)
BTW, this is how the bug evolved over time:
g/x /home/bangerth/bin/gcc-4.0-pre/bin/c++ -c x.cc
x.cc: In function `int main()':
x.cc:9: warning: 'operator 1' is
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-12 16:23
---
This patch fixes it, I will submit it soon:
Index: semantics.c
===
RCS file: /cvs/gcc/gcc/gcc/cp/semantics.c,v
retrieving revision 1.446
diff
I expect the following program to produce the following output:
a 2
b 1 1
i.e, two elements go into the set, we delete one, and one remains.
However, when i compile this with the current cvs head, the program
actually does the following:
$ g++ -g -o x x.cc
$ ./x
a 2
b 0 1
$
i.e., two
--
What|Removed |Added
Version|0.0 |4.0.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17948
--- Additional Comments From pcarlini at suse dot de 2004-10-12 16:57 ---
I'm guilty of this, sorry, your patch looks correct. Will deal with this later
today.
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-12 17:04
---
Note for the C++ front-end at this point we don't warn for the last for statement but
we do for C, I
have a fix for the problem (I fixed while fixing another problem).
--
IA64 sets STRICT_ALIGNMENT to 1 but the tree loop optimizer is converting byte
loads into a unaligned word load (and thus creating an unaligned access).
The attached program compiles and runs with no optimization, fails with -O1 and
works with -O1 -fno-tree-loop-optimize. With -O1 running the
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-12 17:16
---
I send out the email for the patch but it looks like the web archiver is not working.
--
What|Removed |Added
--- Additional Comments From pcarlini at suse dot de 2004-10-12 17:17 ---
Everything considered, if we have to use an additional iterator next, probably is
better just reverting my stupid change and return to:
while (__first != __last)
erase(__first++);
--
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-10-12 17:21
---
Subject: Bug 17931
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2004-10-12 17:14:43
Modified files:
gcc: ChangeLog
gcc/config/i386:
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-12 17:25
---
Confirmed, this is caused by IV-OPTS.
--
What|Removed |Added
CC|
--- Additional Comments From rth at gcc dot gnu dot org 2004-10-12 17:39 ---
Ah, I see some amount of confusion here.
Yes, in the referenced message I do argue for asm volatile to be a scheduling
barrier. You'll note that what I'm most concerned about there is that the asm
remain in
The following test case illustrates an example where dcbtst instructions are
being inserted too aggressively during FDO.
Test Case:
typedef struct {
union {
short arr[64];
short arr2[8][8];
}un;
} str, *strPtr;
str blah;
int main (int argc, char *argv[])
{
int i, x, y;
The dominance info is incorrect for entry and exit blocks.
According to dominated_by_p, nothing dominates the exit block (which is wrong),
and nothing post-dominates the entry block (which is also wrong).
A simple example:
(gdb) p dominated_by_p (CDI_POST_DOMINATORS, ENTRY_BLOCK_PTR,
--
What|Removed |Added
CC||rakdver at gcc dot gnu dot
||org
Component|target
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-12 17:53
---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-12 17:57
---
Fixed.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
With window managers that support _NET_REQUEST_FRAME_EXTENTS no AWT (or Swing)
windows ever show. There is only the following error message.
(:6725): Gdk-WARNING **: /home/mark/sources/gtk+/gdk/x11/gdkdrawable-x11.c:912
drawable is not a pixmap or window
This was caused by the patch that delayed
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Last reconfirmed|-00-00 00:00:00
--- Additional Comments From dalej at apple dot com 2004-10-12 18:30 ---
OK, thanks. From this it appears that the only effect of 'asm volatile' that users
can safely rely on is that such an instruction will not be deleted. If this is
agreeable to everybody, I will revise the
Debian Bug #276224:
-- If the expected type for an expression or name is some specific
-- tagged type, then the expression or name shall not be dynamically
-- tagged unless it is a controlling operand in a call on a
-- dispatching operation.
procedure Test_121 is
package pak1 is
type
--- Additional Comments From gdr at cs dot tamu dot edu 2004-10-12 18:51 ---
Subject: Re: [3.4/4.0 regression] local classes as template argument
mmitchel at gcc dot gnu dot org [EMAIL PROTECTED] writes:
[...]
| Consider:
|
| template typename T
| void f(T *);
|
| void g() {
--- Additional Comments From trt at acm dot org 2004-10-12 18:52 ---
Given the problem pointed out in
http://gcc.gnu.org/ml/gcc-patches/2004-10/msg01013.html I do not see how this
patch can be readily made to work. To avoid redundant truthvalue conversion it
might be necessary e.g. to
Debian Bug #276227:
-- interestingly, the error message is different depending on
-- the number of enumeration elements in T1 and T2.
package Test_124 is
type T1 is (b01,b02,b03,b04,b05,b06,b07,b08,b09,b10,
b11,b12,b13,b14,b15,b16,b17,b18,b19,b20,
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-10-12 19:07
---
Subject: Bug 17952
CVSROOT:/cvs/gcc
Module name:gcc
Branch: java-gui-branch
Changes by: [EMAIL PROTECTED] 2004-10-12 19:07:48
Modified files:
libjava:
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-12 19:20
---
Note this is not a really a regression, the main issue I see here is that we are ifcvt
if(a) 1 else 0; to a and
then we copy the return part (the movzbl and ret) on the other branch but we don't
combine
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-12 19:45
---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
--- Additional Comments From hjl at lucon dot org 2004-10-12 19:52 ---
You are right. The second patch isn't needed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17311
--- Additional Comments From jgrimm2 at us dot ibm dot com 2004-10-12 19:56
---
patch for powerpc64-linux-gnu:
http://gcc.gnu.org/ml/gcc-patches/2004-10/msg01037.html
Index: gcc/config/host-linux.c
===
RCS file:
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-12 20:31
---
I cannot reproduce this on powerpc-darwin.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17527
PR/17892 was filed because gcc-4.0 performs an unsafe optimization of (X*C)*C into
X*(C*C).
Fix to this PR prevents certain safe transformation; such as X*2.0*2.0-X*4.0 from
taking place.
This PR is to track this enhancement.
--
Summary: Perform associative optimization when it is
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-10-12 20:50
---
Subject: Bug 17892
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2004-10-12 20:50:08
Modified files:
gcc: ChangeLog tree-outof-ssa.c
--- Additional Comments From fjahanian at apple dot com 2004-10-12 20:57 ---
tree-outof-ssa.c is not part of this patch. I accidentally checked it in. I have since
backed it out.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17892
--- Additional Comments From rth at gcc dot gnu dot org 2004-10-12 21:26 ---
This is essentially a duplicate of pr17503. I'm backporting the patch from
that PR from mainline to the 3.4 branch. With that, compilation time for
the testcase is 1 minute instead of 30.
--
What
--- Additional Comments From tobi at gcc dot gnu dot org 2004-10-12 21:26 ---
(In reply to comment #4)
I tried this same program with g95 before I submitted a bug and got what
I thought was the correct results without needing the additional _8 .
Do the standards specify that default
--- Additional Comments From tobi at gcc dot gnu dot org 2004-10-12 21:37 ---
No, that's not sufficient. mpfr_set_str apparently doesn't like spaces in constants.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17941
This causes an Ada bootstrap, ../../xgcc -B../../ -c -g -O2 -W -Wall -gnatpg
s-fore.adb -o s-fore.o
The trees look like:
natural___XDLU_0__2147483647 r;
long_long_float t;
bb 0:
t = MAX_EXPR ABS_EXPR lo, ABS_EXPR hi;
if (t = 1.0e+1 == 0) goto L11; else goto L12;
L11:;
r = 2;
goto bb
--
What|Removed |Added
Target Milestone|--- |4.0.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17956
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-12 21:59
---
Confirmed on the mainline:
+===GNAT BUG
DETECTED==+
| 4.0.0 20041012 (experimental) (powerpc-apple-darwin7.4.1) GCC error: |
| in gnat_to_gnu_entity
. */
... and by forcing garbage collection to happen frequently, like so.
laptop% /home/janis/tools/gcc-mline-20041012/bin/gcc -c --param ggc-min-expand=0
--param ggc-min-heapsize=0 bug1.c
bug1.c: In function 'vsub':
bug1.c:17: internal
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-12 21:59
---
Confirmed on the mainline:
+===GNAT BUG
DETECTED==+
| 4.0.0 20041012 (experimental) (powerpc-apple-darwin7.4.1) GCC error: |
| in save_gnu_tree
--- Additional Comments From janis187 at us dot ibm dot com 2004-10-12 22:00
---
Created an attachment (id=7331)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7331action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17957
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-12 22:00
---
Confirmed on the mainline:
+===GNAT BUG
DETECTED==+
| 4.0.0 20041012 (experimental) (powerpc-apple-darwin7.4.1) GCC error
--
What|Removed |Added
CC||pinskia at gcc dot gnu dot
||org
Keywords|
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-12 22:28
---
Fixed.
--
What|Removed |Added
Status|NEW |RESOLVED
expand_divmod cannot optimize code such as
long long div10(long long n) { return n / 10; }
when BITS_PER_WORD is 32. A call to __divdi3 gets generated. By contrast, when
BITS_PER_WORD is 64, this is optimized to a multiply and a shift. I noticed
this problem on powerpc32, but it ought to
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-12 22:55
---
not all constants though (power of 2 are fine) for an example 16:
mr r12,r3
srawi r11,r3,31
srawi r9,r11,31
srawi r10,r11,31
srwi r10,r9,28
li r9,0
unsigned long long div16(unsigned long long n) { return n / 16; }
Without -mpowerpc64:
_div16:
slwi r0,r3,28
srwi r4,r4,4
or r4,r0,r4
srwi r3,r3,4
blr
With:
_div16:
li r0,0
rldimi r0,r3,32,0
rldimi r0,r4,0,32
srdi r4,r0,4
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Last reconfirmed|-00-00 00:00:00
1 - 100 of 138 matches
Mail list logo
