[Bug target/20928] [4.0/4.1 regression] ICE: unrecognizable insns
--- Additional Comments From aj at gcc dot gnu dot org 2005-05-21 07:00 --- Steven, any update on this one? Would you like to get it assigned to? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20928
[Bug target/21314] C++ size and performance regression with -Os
--- Additional Comments From deemkay at gmail dot com 2005-05-21 07:33 --- i think this might be a dupe of #21529, and the original person who provided the code has also opened a PR (although for a different reason), so i'd like to close this. thanks anyways. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21314
[Bug tree-optimization/21694] New: Missed forwprop opportunity into COND_EXPR
Consider:
enum tree_code {
AAA,
BBB,
CCC
};
struct tree_common {
enum tree_code code : 8;
};
int
foo (struct tree_common *p)
{
enum tree_code code = p->code;
if (code == 0)
return p->code;
return 123;
}
After forwprop, the code leading up to the COND_EXPR looks like so:
D.1240_3 = p_2->code;
code_4 = (tree_code) D.1240_3;
if (code_4 == 0) goto ; else goto ;
After DOM, the code leading up to the COND_EXPR looks like so:
D.1240_3 = p_2->code;
code_4 = (tree_code) D.1240_3;
if (D.1240_3 == 0) goto ; else goto ;
Note that the COND_EXPR now uses D.1240_3.
--
Summary: Missed forwprop opportunity into COND_EXPR
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kazu at cs dot umass dot edu
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21694
[Bug java/21695] New: ICE when building gnu-xml.lo in libjava directory
GCC version: 4.0.0 release Host = Target = Build = Cygwin (i686-pc-cygwin) I configure with: ../gcc-4.0.0/configure --prefix=/usr/local --sysconfdir=/etc --program-suffix=-4 \ --enable-threads=posix --enable-version-specific-runtime-libs \ --enable-languages=c,ada,c++,f95,java,objc,treelang --disable-win32-registry --disable-nls \ --enable-sjlj-exceptions --with-system-zlib --enable-libgcj Then, during "make bootstrap-lean" all goes fine until the following: /bin/sh ./libtool --mode=compile /tmp/gcc4/build/gcc/gcj -B/tmp/gcc4/build/gcc/ -B/usr/local/i686-pc-cygwin/bin/ -B/usr/local/i686-pc-cygwin/lib/ -isystem /usr/local/i686-pc-cygwin/include -isystem /usr/local/i686-pc-cygwin/sys-include -ffloat-store -fno-omit-frame-pointer -fclasspath= -fbootclasspath=/tmp/gcc4/build/i686-pc-cygwin/libjava':'../../../gcc-4.0.0/libjava':'../../../gcc-4.0.0/libjava/external/w3c_dom':'../../../gcc-4.0.0/libjava/external/sax --encoding=UTF-8 -Wno-deprecated -g -O2 -fjni -findirect-dispatch -c -o gnu-xml.lo \ `find gnu/xml -name '*.class' -print | sort -r` ..which gives the following error: gnu/xml/dom/DomDOMException.java:171: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. make[3]: *** [gnu-xml.lo] Error 1 Thinking that it might be a problem with the long command line (the 'find' expands to a large number of .class files) I tried mounting my build directory "cygexec" (which is a feature of cygwin that sidesteps windows limitations on environment and command line length.) Unfortunately this did not make a difference. The full expanded compile line is below: /tmp/gcc4/build/gcc/gcj -B/tmp/gcc4/build/gcc/ -B/usr/local/i686-pc-cygwin/bin/ -B/usr/local/i686-pc-cygwin/lib/ -isystem /usr/local/i686-pc-cygwin/include -isystem /usr/local/i686-pc-cygwin/sys-include -ffloat-store -fno-omit-frame-pointer -fclasspath= -fbootclasspath=/tmp/gcc4/build/i686-pc-cygwin/libjava:../../../gcc-4.0.0/libjava:../../../gcc-4.0.0/libjava/external/w3c_dom:../../../gcc-4.0.0/libjava/external/sax --encoding=UTF-8 -Wno-deprecated -g -O2 -fjni -findirect-dispatch -c gnu/xml/xpath/XPathTokenizer.class gnu/xml/xpath/XPathTokenizer\$XPathToken.class gnu/xml/xpath/XPathParser.class gnu/xml/xpath/XPathParser\$yyInput.class gnu/xml/xpath/XPathParser\$yyException.class gnu/xml/xpath/XPathParser\$YyTableClass.class gnu/xml/xpath/XPathParser\$YySindexClass.class gnu/xml/xpath/XPathParser\$YyRindexClass.class gnu/xml/xpath/XPathParser\$YyNameClass.class gnu/xml/xpath/XPathParser\$YyLhsClass.class gnu/xml/xpath/XPathParser\$YyLenClass.class gnu/xml/xpath/XPathParser\$YyGindexClass.class gnu/xml/xpath/XPathParser\$YyDgotoClass.class gnu/xml/xpath/XPathParser\$YyDefRedClass.class gnu/xml/xpath/XPathParser\$YyCheckClass.class gnu/xml/xpath/XPathImpl.class gnu/xml/xpath/XPathFactoryImpl.class gnu/xml/xpath/VariableReference.class gnu/xml/xpath/UnionExpr.class gnu/xml/xpath/TrueFunction.class gnu/xml/xpath/TranslateFunction.class gnu/xml/xpath/Test.class gnu/xml/xpath/SumFunction.class gnu/xml/xpath/SubstringFunction.class gnu/xml/xpath/SubstringBeforeFunction.class gnu/xml/xpath/SubstringAfterFunction.class gnu/xml/xpath/StringLengthFunction.class gnu/xml/xpath/StringFunction.class gnu/xml/xpath/Steps.class gnu/xml/xpath/StartsWithFunction.class gnu/xml/xpath/Selector.class gnu/xml/xpath/RoundFunction.class gnu/xml/xpath/Root.class gnu/xml/xpath/RelationalExpr.class gnu/xml/xpath/Predicate.class gnu/xml/xpath/PositionFunction.class gnu/xml/xpath/Pattern.class gnu/xml/xpath/Path.class gnu/xml/xpath/ParenthesizedExpr.class gnu/xml/xpath/OrExpr.class gnu/xml/xpath/NumberFunction.class gnu/xml/xpath/NotFunction.class gnu/xml/xpath/NormalizeSpaceFunction.class gnu/xml/xpath/NodeTypeTest.class gnu/xml/xpath/NegativeExpr.class gnu/xml/xpath/NamespaceUriFunction.class gnu/xml/xpath/NamespaceTest.class gnu/xml/xpath/NameTest.class gnu/xml/xpath/NameFunction.class gnu/xml/xpath/LocalNameFunction.class gnu/xml/xpath/LastFunction.class gnu/xml/xpath/LangFunction.class gnu/xml/xpath/IdFunction.class gnu/xml/xpath/FunctionCall.class gnu/xml/xpath/Function.class gnu/xml/xpath/FloorFunction.class gnu/xml/xpath/FalseFunction.class gnu/xml/xpath/Expr.class gnu/xml/xpath/EqualityExpr.class gnu/xml/xpath/DocumentOrderComparator.class gnu/xml/xpath/CountFunction.class gnu/xml/xpath/ContainsFunction.class gnu/xml/xpath/Constant.class gnu/xml/xpath/ConcatFunction.class gnu/xml/xpath/CeilingFunction.class gnu/xml/xpath/BooleanFunction.class gnu/xml/xpath/ArithmeticExpr.class gnu/xml/xpath/AndExpr.class gnu/xml/util/XMLWriter.class gnu/xml/util/XHTMLWriter.class gnu/xml/util/XCat.class gnu/xml/util/XCat\$Loader.class gnu/xml/util/XCat\$DoneDelegation.class gnu/xml/util/XCat\$Catalog.class gnu/xml/util/SAXNullTransformerFactory.class gnu/xml/util/SAXNullTransformerFactory\$NullTransformer.class gnu/xml/util/SAXNullTransformerFactory\$NullHandler.class g
[Bug libfortran/21547] Enable to build libfortran library
-- What|Removed |Added CC||christian dot joensson at ||gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21547
[Bug tree-optimization/21694] Missed forwprop opportunity into COND_EXPR
--- Additional Comments From kazu at cs dot umass dot edu 2005-05-21 09:45 --- The DOM's optimization comes from find_equivalent_equality_comparison, which makes a COND_EXPR absorb a narrowing cast. We could port this to tree-ssa-forwprop.c. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21694
[Bug c++/21696] New: definition not defined to linker
In the attached source there are several definitions of the form: template<> checker subBuff::checks; As shown in the attached output from "nm", these are reported in the .o file as references not definitions: U _ZN7subBuffI6readerE6checksE However, if the definition is explicitly initialized as in: template<> checker subBuff::checks = checker(); then the nm output shows that it is defined: 0062 B _ZN7subBuffI4phizE6checksE These should all be reported as definitions. Ivan -- Summary: definition not defined to linker Product: gcc Version: 3.4.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: igodard at pacbell dot net CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21696
[Bug c++/21696] definition not defined to linker
--- Additional Comments From igodard at pacbell dot net 2005-05-21 10:01 --- Created an attachment (id=8942) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8942&action=view) compiler output -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21696
[Bug c++/21696] definition not defined to linker
--- Additional Comments From igodard at pacbell dot net 2005-05-21 10:02 --- Created an attachment (id=8943) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8943&action=view) linker symbols as reported by "nm" -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21696
[Bug c++/21696] definition not defined to linker
--- Additional Comments From igodard at pacbell dot net 2005-05-21 10:02 --- Created an attachment (id=8944) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8944&action=view) source code (compressed) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21696
[Bug middle-end/21597] [4.1 Regression] libgcc broken on targets with MKDIR_TAKES_ONE_ARG
--- Additional Comments From fxcoudert at gmail dot com 2005-05-21 10:03 --- On i386-mingw32, there is another one of those: ../../gcc/fastjar/jartool.c: In function 'extract_jar': ../../gcc/fastjar/jartool.c:1770: error: too many arguments to function 'mkdir' Looks like MKDIR_TAKES_ONE_ARG is not defined as it should be. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21597
[Bug tree-optimization/21694] Missed forwprop opportunity into COND_EXPR
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-21 12:38 --- There is a reason why forwprop does not do this, the SSA_NAME is used twice. If we run forwprop before FRE, it will catch it in this See PR 19703 for a case where DOM messes up catching something like this. I think forwprop already does this in some cases but I could be wrong. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21694
[Bug c++/21693] private member is accessible by a derived class when declaring and defining classes in the same file
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-21 12:44 --- Fixed in 3.4.0 and above. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Keywords||accepts-invalid Known to fail||2.95.3 3.0.4 3.2.3 3.3.3 Known to work||3.4.0 4.0.0 4.1.0 Resolution||FIXED Target Milestone|--- |3.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21693
[Bug c++/21696] definition not defined to linker
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-21 12:46 --- You are just specializing the template member and not instainationing them. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21696
[Bug tree-optimization/18441] Vectorizer: add a command line for simple vectorizer report
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-21 12:51 --- Fixed for 4.0.0. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18441
[Bug tree-optimization/19633] local address incorrectly thought to escape
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-21 12:52 --- Should this be closed? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19633
[Bug tree-optimization/21568] [4.0/4.1 regression] Casts in folding *& omitted
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-05-21
13:50 ---
The only construct I can make gcc deal with mixed (non-)volatile qualifiers
is a union like in
union {
volatile int x;
int y;
} u;
int foo(void)
{
u.y = 0;
return u.x;
}
--
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21568
[Bug fortran/21673] gfortran binary file format
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-21 13:52 --- *** This bug has been marked as a duplicate of 19303 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21673
[Bug libfortran/19303] Unformatted record header is 4-bytes on 32-bit targets
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-21 13:53 --- *** Bug 21673 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19303
[Bug java/21662] [3.4/4.0/4.1 Regression] Fields in interfaces not optimized when read from *.class, but optimized when read from *.java
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-21 14:01 --- Confirmed, in 3.2.3, we produced the same class file. -- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||missed-optimization Known to fail||3.3.3 3.4.0 4.0.0 4.1.0 Known to work||3.2.3 Last reconfirmed|-00-00 00:00:00 |2005-05-21 14:01:59 date|| Summary|Fields in interfaces not|[3.4/4.0/4.1 Regression] |optimized when read from|Fields in interfaces not |*.class, but optimized when |optimized when read from |read from *.java|*.class, but optimized when ||read from *.java Target Milestone|--- |4.0.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21662
[Bug java/21662] [3.4/4.0/4.1 Regression] Fields in interfaces not optimized when read from *.class, but optimized when read from *.java
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-21 14:03 --- (In reply to comment #1) > Confirmed, in 3.2.3, we produced the same class file. Oh and optimized it correctly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21662
[Bug tree-optimization/21655] g++.dg/tree-ssa/pr14814.C scan-tree-dump-times &this 0 fails
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-21 14:03 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-05-21 14:03:59 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21655
[Bug c++/21667] misleading warning about array subscription
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-21 14:04 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||diagnostic Last reconfirmed|-00-00 00:00:00 |2005-05-21 14:04:44 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21667
[Bug c/21668] gratuitous warning about "extern const" with initializer
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-21 14:06 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 GCC host triplet|plateform independent | Keywords||diagnostic Known to fail||2.95.3 3.0.4 3.2.3 3.3.3 ||3.4.0 4.0.0 Last reconfirmed|-00-00 00:00:00 |2005-05-21 14:06:40 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21668
[Bug libfortran/21547] Enable to build libfortran library
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-21 14:09 --- ld.so.1: ($MYPATH)/gcc/gcc/f951: fatal: libgmp.so.3: open failed: No such file or directory This means that libgmp is not in your LD_LIBRARY_PATH. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21547
[Bug libstdc++/21674] basic_string vs debug_mode
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-21 14:13 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-05-21 14:13:55 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21674
[Bug middle-end/20329] regression: current 3.4.4 miscompiles Linux kernel with athlon optimisations
--- Additional Comments From bero at arklinux dot org 2005-05-21 14:30
---
I haven't been able to find a short piece of code triggering this problem, but
using a fairly stupid script ("while true; do check out older version;
compile; see if problem persists; done"), I've found the problem appears with
the fix for target/19803.
Reverting this patch fixes the problem.
--
What|Removed |Added
Status|WAITING |NEW
Ever Confirmed||1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20329
[Bug c++/21682] Disallowed using declaration
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-21
14:35 ---
Confirmed, reduced testcase (which shows the problem):
template
struct t
{
typedef typename T::type type;
};
template<> class t{};
template struct t1{ };
template<> struct t1
{
typedef int type;
};
namespace name1
{
template typename t::type begin(S const& s);
namespace name2
{
template typename t1::type begin(S const& s);
}
using name2::begin;
}
/* Test calling the function. */
int f(int a) { return name1::begin(a); }
struct aa { typedef double type; };
double g(aa t) { return name1::begin(t); }
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Keywords||rejects-valid
Last reconfirmed|-00-00 00:00:00 |2005-05-21 14:35:40
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21682
[Bug middle-end/20329] [3.4 regression]: current 3.4.4 miscompiles Linux kernel with athlon optimisations
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-21 14:37 --- (In reply to comment #2) > Reverting this patch fixes the problem. There is a latent bug somewhere else. We still need a testcase. -- What|Removed |Added Status|NEW |WAITING Summary|regression: current 3.4.4 |[3.4 regression]: current |miscompiles Linux kernel|3.4.4 miscompiles Linux |with athlon optimisations |kernel with athlon ||optimisations Target Milestone|--- |3.4.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20329
[Bug c++/21681] [4.0/4.1 Regression] Internal Compiler Error
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-21
14:49 ---
Confirmed, reduced testcase:
template struct dispatch { typedef int result; };
struct copy_
{
template
typename dispatch::result
operator()(Range1 const& src) const
{
return dispatch::a::execute(src);
}
};
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Keywords||ice-on-valid-code
Last reconfirmed|-00-00 00:00:00 |2005-05-21 14:49:05
date||
Target Milestone|--- |4.0.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21681
[Bug target/21684] MCore testsuite file gcc.c-torture/execute/lshrdi3-1.c compiles to incorrect assembly
-- What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2005- ||05/msg02109.html Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||patch Last reconfirmed|-00-00 00:00:00 |2005-05-21 14:49:43 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21684
[Bug java/21697] New: gcj segfaults with Jabref.jar
[ forwarded from http://bugs.debian.org/278642 ] With this jar file: http://mesh.dl.sourceforge.net/sourceforge/jabref/Jabref-1.5.jar both 3.3.6 and 3.4.4 segfault. [EMAIL PROTECTED]:/tmp% gcj-3.3 Jabref-1.5.jar antlr/PreservingFileWriter.java: In class `antlr.PreservingFileWriter': antlr/PreservingFileWriter.java: In method `antlr.PreservingFileWriter.close()': antlr/PreservingFileWriter.java:56: warning: exception handler inside code that is being protected gcj-3.3: Internal error: Segmentation fault (program jc1) [EMAIL PROTECTED]:/tmp% gcj-3.4 Jabref-1.5.jar gcj-3.4: Internal error: Segmentation fault (program jc1) -- Summary: gcj segfaults with Jabref.jar Product: gcc Version: 3.4.4 Status: UNCONFIRMED Severity: normal Priority: P2 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: debian-gcc at lists dot debian dot org CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21697
[Bug java/21697] gcj segfaults with Jabref.jar
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-21 14:54 --- With the mainline, I get: antlr/TokenStreamRewriteEngine.java:0: error: cannot find file for class antlr.TokenStreamRewriteEngine$RewriteOperation antlr/TokenStreamRewriteEngine.java:0: error: cannot find file for class antlr.TokenStreamRewriteEngine$InsertBeforeOp antlr/TokenStreamRewriteEngine.java:0: error: cannot find file for class antlr.TokenStreamRewriteEngine$ReplaceOp antlr/TokenStreamRewriteEngine.java:0: error: cannot find file for class antlr.TokenStreamRewriteEngine$DeleteOp java/util/HashMap.java: In class 'antlr.TokenStreamRewriteEngine': java/util/HashMap.java: In method 'antlr.TokenStreamRewriteEngine.addToSortedRewriteList(java.lang.String,antlr.TokenStreamRewriteEngi ne$RewriteOperation)': java/util/HashMap.java:191: error: cannot find file for class antlr.TokenStreamRewriteEngine$1 java/util/HashMap.java:191: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21697
[Bug tree-optimization/21694] Missed forwprop opportunity into COND_EXPR
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-21
15:01 ---
Confirmed, here is a testcase which makes sure that we don't have to worry
about the one use property
of forwprop:
enum tree_code {
AAA,
BBB,
CCC
};
struct tree_common {
enum tree_code code : 8;
};
int
foo (struct tree_common *p)
{
enum tree_code code = p->code;
if (code == 0)
return 1000;
return 123;
}
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed||1
Last reconfirmed|-00-00 00:00:00 |2005-05-21 15:01:02
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21694
[Bug c++/21645] [4.1 Regression] C++ ICE in cxx_types_compatible_p
--- Additional Comments From ahaas at airmail dot net 2005-05-21 15:39 --- I applied the patch, rebuilt, installed, and can confirm the patch works as I had a successful groff CVS build. Thanks! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21645
[Bug bootstrap/21698] New: creating first stage compiler
hello, I'm currently trying to create x86_64 crosschain and found several issues : 1)glibc won't compile on linux plateforms if threads aren't compiled 2)methods given on the wiki help to create a 1rst stage crosscompiler that can't compile glibc with threads this issue is fixed by installing glibc's headers on the target filesystem first and then create the crosscompiler but strangely there is a new issue that appears then : the ./xgcc commands in gcc/Makefile.in dont use the --with-local-prefix= as -isystem => headers of the "target" aren't used then thread support can't be activated, then glibc can't be compiled... this is fixed by doing : --- gcc-3.4.3/gcc/Makefile.in 2005-05-21 10:35:08.613136000 +0200 +++ gcc-3.4.3-new/gcc/Makefile.in 2005-05-21 11:33:50.124784872 +0200 @@ -286,7 +286,7 @@ # The GCC to use for compiling libgcc.a and crt*.o. # Usually the one we just built. # Don't use this as a dependency--use $(GCC_PASSES) or $(GCC_PARTS). -GCC_FOR_TARGET = $(STAGE_CC_WRAPPER) ./xgcc -B./ -B$(build_tooldir)/bin/ -isystem $(build_tooldir)/include -isystem $(build_tooldir)/sys-include -L$(objdir)/../ld +GCC_FOR_TARGET = $(STAGE_CC_WRAPPER) ./xgcc -B./ -B$(build_tooldir)/bin/ -isystem $(build_tooldir)/include -isystem $(local_prefix)/include -isystem $(build_tooldir)/sys-include -L$(objdir)/../ld but then I get 2 different comportements when compiling gcc : 1) if I compile from the top source directory I get the same result as if the patch wasn't applied (in fact instead of ./xgcc I get /usr/src/sorcery/gcc-3.4.3/gcc/xgcc [/usr/src/sorcery/gcc-3.4.3 is the top build dir]) seems that those values commes from configure script... 2)if I do a cd gcc && make then everything finish fine. and I have a crosscompiler with thread support -- Summary: creating first stage compiler Product: gcc Version: 3.4.3 Status: UNCONFIRMED Severity: normal Priority: P2 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jlm_devel at laposte dot net CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: x86_64-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21698
[Bug bootstrap/21698] creating first stage compiler
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-21 15:43 --- This does not make sense, people create cross compilers to x86_64-pc-linux-gnu all the time. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21698
[Bug c++/21699] New: asm and cast-to-reference -> bad code
The code below is an attempt at having the macro add_ss from GNU
MP accepted by G++. I am casting the outputs of the asm statement to
unsigned int& (in GMP, USItype is unsigned int + attrib SI, which are the
same on i386).
First, I'd like to be told if this is not a reasonable thing to do. I
think it is, but I'm not too sure.
The problem is that g++ 3.4.x produces wrong code at -O2 level for this.
The asm produced has no trace of the two tests at the end (it must,
really). No warning is issued.
The problem vanishes if I cast to unsigned long& instead, or if I remove the
cast.
4.0 does not have the problem.
See also http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2803
---
const unsigned long f_p = 4194301;
extern unsigned long mpinv_mod_r;
unsigned long redc(unsigned long zhi, unsigned long zlo)
{
unsigned long t, u, m, __w1, __xm0, __xm1;
m = zlo * mpinv_mod_r;
__xm0 = m;
__xm1 = f_p;
__asm__("mull %3": "=a"(u), "=d"(__w1):"%0"(__xm0),
"rm"(__xm1));
t = __w1 - (-(__xm0 >> 31) & __xm1) - (-(__xm1 >> 31) & __xm0);
__asm__("addl %5,%1\n\tadcl %3,%0"
: "=r" ((unsigned int&) t), "=&r" ((unsigned int&) u)
:"0"(t), "g"(zhi), "%1"(u), "g"(zlo));
if ((int) t < 0)
t += f_p;
if (t >= f_p)
t -= f_p;
return t;
}
---
E.
--
Summary: asm and cast-to-reference -> bad code
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: thome at lix dot polytechnique dot fr
CC: gcc-bugs at gcc dot gnu dot org
GCC host triplet: i386-redhat-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21699
Re: [Bug c++/21699] New: asm and cast-to-reference -> bad code
On May 21, 2005, at 11:48 AM, thome at lix dot polytechnique dot fr wrote: The code below is an attempt at having the macro add_ss from GNU MP accepted by G++. I am casting the outputs of the asm statement to unsigned int& (in GMP, USItype is unsigned int + attrib SI, which are the same on i386). First, I'd like to be told if this is not a reasonable thing to do. I think it is, but I'm not too sure. The problem is that g++ 3.4.x produces wrong code at -O2 level for this. The asm produced has no trace of the two tests at the end (it must, really). No warning is issued. You are violating C++ aliasing rules. You are accessing a long variable as an int. Thanks, Andrew Pinski
[Bug c++/21699] asm and cast-to-reference -> bad code
--- Additional Comments From Emmanuel dot Thome at inria dot fr 2005-05-21 16:05 --- *** Bug 21700 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21699
[Bug c++/21699] asm and cast-to-reference -> bad code
--- Additional Comments From Emmanuel dot Thome at inria dot fr 2005-05-21 16:09 --- Created an attachment (id=8946) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8946&action=view) asm code at -O2 see how the result of the second adc goes straight as a return value. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21699
[Bug c++/21699] asm and cast-to-reference -> bad code
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-21 16:21 --- You are violating C++ aliasing rules. You are accessing a long variable as an int. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21699
[Bug c++/21699] asm and cast-to-reference -> bad code
--- Additional Comments From Emmanuel dot Thome at inria dot fr 2005-05-21 16:42 --- (In reply to comment #3) > You are violating C++ aliasing rules. > You are accessing a long variable as an int. > ok. I'll try to have gmp fixed then. shouldn't -Wstrict-aliasing issue a warning in such a situation ? E. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21699
[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations
--- Additional Comments From aj at suse dot de 2005-05-21 16:50 --- Subject: Re: libstdc++ headers should have pop/push of the visibility around the declarations "mark at codesourcery dot com" <[EMAIL PROTECTED]> writes: > Then, can it not be left disabled for 4.0.x as well? It could - but people do want to use it. This is a rather important improvement and people have been waiting for this feature to see it in production since some time now. Andreas -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
[Bug middle-end/21331] [4.0 Regression] Incorrect folding of comparison
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-21 16:57 --- Subject: Bug 21331 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-05-21 16:57:25 Modified files: gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.c-torture/compile: pr21293.c gcc/testsuite/gcc.c-torture/execute: pr21331.c Log message: 2004-05-21 Andrew Pinski <[EMAIL PROTECTED]> PR middle-end/21331 PR tree-opt/21293 * gcc.c-torture/compile/pr21293.c: New test. * gcc.c-torture/execute/pr21331.c: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5504&r2=1.5505 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/compile/pr21293.c.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/execute/pr21331.c.diff?cvsroot=gcc&r1=NONE&r2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21331
[Bug tree-optimization/21293] [4.0 Regression] ICE in set_value_handle
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-21 16:57 --- Subject: Bug 21293 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-05-21 16:57:25 Modified files: gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.c-torture/compile: pr21293.c gcc/testsuite/gcc.c-torture/execute: pr21331.c Log message: 2004-05-21 Andrew Pinski <[EMAIL PROTECTED]> PR middle-end/21331 PR tree-opt/21293 * gcc.c-torture/compile/pr21293.c: New test. * gcc.c-torture/execute/pr21331.c: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5504&r2=1.5505 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/compile/pr21293.c.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/execute/pr21331.c.diff?cvsroot=gcc&r1=NONE&r2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21293
[Bug middle-end/21331] [4.0 Regression] Incorrect folding of comparison
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-21 16:58 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21331
[Bug tree-optimization/21293] [4.0 Regression] ICE in set_value_handle
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-21 16:58 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21293
[Bug middle-end/21331] [4.0 Regression] Incorrect folding of comparison
-- Bug 21331 depends on bug 21293, which changed state. Bug 21293 Summary: [4.0 Regression] ICE in set_value_handle http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21293 What|Old Value |New Value Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21331
[Bug middle-end/21331] [4.0 Regression] Incorrect folding of comparison
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-21 16:59 --- Subject: Bug 21331 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-05-21 16:58:46 Modified files: gcc: ChangeLog tree-cfg.c tree-gimple.c gcc/fortran: ChangeLog trans-intrinsic.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.c-torture/compile: pr21293.c gcc/testsuite/gcc.c-torture/execute: pr21331.c Log message: 2005-05-21 Andrew Pinski Backport from the mainline: 2005-03-14 Zdenek Dvorak <[EMAIL PROTECTED]> * fortran/trans-intrinsic.c (gfc_conv_intrinsic_ishft): Convert the argument of the shift to the unsigned type. 2005-05-21 Andrew Pinski <[EMAIL PROTECTED]> PR middle-end/21331 PR tree-opt/21293 Backport from the mainline: 2005-03-14 Zdenek Dvorak <[EMAIL PROTECTED]> * tree-cfg.c (find_taken_edge_cond_expr): Use zero_p instead of integer_zerop. * tree-gimple.c (is_gimple_min_invariant): Consider overflowed constants invariant. 2004-05-21 Andrew Pinski <[EMAIL PROTECTED]> PR middle-end/21331 PR tree-opt/21293 * gcc.c-torture/compile/pr21293.c: New test. * gcc.c-torture/execute/pr21331.c: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=2.7592.2.256&r2=2.7592.2.257 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-cfg.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=2.151&r2=2.151.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-gimple.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=2.35&r2=2.35.12.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.335.2.53&r2=1.335.2.54 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-intrinsic.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.43.10.4&r2=1.43.10.5 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.5084.2.191&r2=1.5084.2.192 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/compile/pr21293.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/execute/pr21331.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21331
[Bug tree-optimization/21293] [4.0 Regression] ICE in set_value_handle
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-21 16:59 --- Subject: Bug 21293 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-05-21 16:58:46 Modified files: gcc: ChangeLog tree-cfg.c tree-gimple.c gcc/fortran: ChangeLog trans-intrinsic.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.c-torture/compile: pr21293.c gcc/testsuite/gcc.c-torture/execute: pr21331.c Log message: 2005-05-21 Andrew Pinski Backport from the mainline: 2005-03-14 Zdenek Dvorak <[EMAIL PROTECTED]> * fortran/trans-intrinsic.c (gfc_conv_intrinsic_ishft): Convert the argument of the shift to the unsigned type. 2005-05-21 Andrew Pinski <[EMAIL PROTECTED]> PR middle-end/21331 PR tree-opt/21293 Backport from the mainline: 2005-03-14 Zdenek Dvorak <[EMAIL PROTECTED]> * tree-cfg.c (find_taken_edge_cond_expr): Use zero_p instead of integer_zerop. * tree-gimple.c (is_gimple_min_invariant): Consider overflowed constants invariant. 2004-05-21 Andrew Pinski <[EMAIL PROTECTED]> PR middle-end/21331 PR tree-opt/21293 * gcc.c-torture/compile/pr21293.c: New test. * gcc.c-torture/execute/pr21331.c: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=2.7592.2.256&r2=2.7592.2.257 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-cfg.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=2.151&r2=2.151.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-gimple.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=2.35&r2=2.35.12.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.335.2.53&r2=1.335.2.54 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-intrinsic.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.43.10.4&r2=1.43.10.5 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.5084.2.191&r2=1.5084.2.192 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/compile/pr21293.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/execute/pr21331.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21293
[Bug tree-optimization/21694] Missed forwprop opportunity into COND_EXPR
--- Additional Comments From kazu at cs dot umass dot edu 2005-05-21 17:01 --- (In reply to comment #2) > There is a reason why forwprop does not do this, the SSA_NAME is used twice. If we run forwprop > before FRE, it will catch it in this We are interested in the number of immediate uses of cond_4, not D.1240_3. Since cond_4 is used only once, this optimization fits in the framework of forwprop quite nicely. I've got a patch. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |kazu at cs dot umass dot edu |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21694
[Bug tree-optimization/21568] [4.0/4.1 regression] Casts in folding *& omitted
--- Additional Comments From schlie at comcast dot net 2005-05-21 17:31 --- (In reply to comment #1) > This is undefined, see the full discussion on the gcc list: > http://gcc.gnu.org/ml/gcc/2005-05/msg00073.html - out of curiosity, it's not clear that the discussion reached any conclusion which enables GCC to disreguard the type semantics as specifed by the program code. Where in the standard does it specify that a type qualifier may be disreguarded if convenient? (candidly, I would have exected the specifed rvalue reference to x to force x's logical value into memory if not previously done, and then subsequently re-accessed to satisfy the union of both semantic interpretations.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21568
[Bug bootstrap/21698] creating first stage compiler
--- Additional Comments From jlm_devel at laposte dot net 2005-05-21 17:50 --- maybe, I can too using several workaround like crosstool.sh is doing but this lead to have the target tree be located at the same place of the crosschain which is a nonsens... why a target filesystem's location MUST depend on where the chain is located? anyway the issue is related to gcc/libgcc.mk seeking into the logs I found that make gcc-all was doing a make \ CFLAGS="-mtune=athlon64 -O2 -pipe -Wno-deprecated-declarations -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long " \ CONFIG_H="config.h auto-host.h ./../include/ansidecl.h" \ MAKEOVERRIDES= \ -f libgcc.mk all which fail on the other hand when doing a make all in gcc/ you still get the right libgcc.a so i'll make a patch anyway since you're using gnu make why are the Makefiles such a mess (lot of redefines, no use of include) so I still maintain that the --with-local-prefix= in configure should be used to give information where the headers are located (all the docs I read say so) and that there is an issue with libgcc.mk as you say peoples are doing crosscompiler everyday but look at crosstool.sh 's hacks to be sure there are a issue by the way : should the gcc libraries not be independant of a libc? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21698
[Bug c++/21701] New: No flag to turn off warning: warning: template-argument `' uses anonymous type
We are currently discussing this issue in the Core Working group of the ISO C++ committee. Currently there is not agreement that such an instantiation should be disallowed. In particular, the case of an overloaded operator that operates on enums is under consideration. In any case, there does not seem to be a mechanism to suppress this warning at the moment. -- Summary: No flag to turn off warning: warning: template- argument `' uses anonymous type Product: gcc Version: 3.3 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mmarcus at emarcus dot org CC: gcc-bugs at gcc dot gnu dot org,gdr at integrable- solutions dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21701
[Bug c++/21701] No flag to turn off warning: warning: template-argument `' uses anonymous type
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-21 18:01 --- *** This bug has been marked as a duplicate of 21514 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21701
[Bug c++/21514] [DR 278] templates and anonymous enum
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-21 18:01 --- *** Bug 21701 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||mmarcus at emarcus dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21514
[Bug tree-optimization/21568] [4.0/4.1 regression] Casts in folding *& omitted
--- Additional Comments From debian-gcc at lists dot debian dot org 2005-05-21 18:10 --- (In reply to comment #3) > (In reply to comment #1) > > This is undefined, see the full discussion on the gcc list: > > http://gcc.gnu.org/ml/gcc/2005-05/msg00073.html > > - out of curiosity, it's not clear that the discussion reached any >conclusion which enables GCC to disreguard the type semantics >as specifed by the program code. Where in the standard does it >specify that a type qualifier may be disreguarded if convenient? See http://gcc.gnu.org/ml/gcc/2005-05/msg00085.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21568
[Bug bootstrap/21698] creating first stage compiler
--- Additional Comments From jlm_devel at laposte dot net 2005-05-21 18:22 --- I re-checked to be sure... and I confirm : $ make all-gcc ... $ echo $? 2 $ cd gcc $ make all ... $ echo $? 0 $ ls libgcc.a libgcc.a so the issue is : two make that should have the same behaviour don't -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21698
[Bug testsuite/21702] New: Typo in gcc/testsuite/gcc.target/i386/i386.exp
Typo at line 19: "SPARC", must be "x86" -- Summary: Typo in gcc/testsuite/gcc.target/i386/i386.exp Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: atrus dot ru at atrus dot ru CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21702
[Bug c++/21701] No flag to turn off warning: warning: template-argument `' uses anonymous type
--- Additional Comments From gdr at integrable-solutions dot net 2005-05-21 18:32 --- Subject: Re: No flag to turn off warning: warning: template-argument `' uses anonymous type "pinskia at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes: | --- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-21 18:01 --- | | | *** This bug has been marked as a duplicate of 21514 *** | | -- |What|Removed |Added | | Status|UNCONFIRMED |RESOLVED | Resolution||DUPLICATE Andrew -- This is a separate bug. It is specifically asking for a flag to turn off the diagnostic. This is a request for a practical solution, while waiting for the committee to seal the details. I you write or port C++ programs, you'll realize how impractical the current implementation/rule is. The enums could come fromo system headers and such. That is entiry different from the one you think this is a duplciate of. Please repoen the PR and mark it as feature request. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21701
[Bug c++/21701] No flag to turn off warning: warning: template-argument `' uses anonymous type
--- Additional Comments From gdr at gcc dot gnu dot org 2005-05-21 18:55 --- People should not hastly close bug PRs without proper analysis. -- What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21701
[Bug testsuite/21702] Typo in gcc/testsuite/gcc.target/i386/i386.exp
--- Additional Comments From atrus dot ru at atrus dot ru 2005-05-21 19:30 --- Created an attachment (id=8947) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8947&action=view) patch -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21702
[Bug java/21703] New: hang when rapidly calling String.intern()
[ forwarded from http://bugs.debian.org/275547 ]
[EMAIL PROTECTED]:/tmp% cat Test.java
class Test {
public static void main(String[] argv) {
for (char i = '\u0001'; i <= '\u'; i++) {
char[] ca = { i };
System.out.println("Interning "+((int)i)+"th String");
(new String(ca)).intern();
}
}
}
[EMAIL PROTECTED]:/tmp% gcj-3.4 -o Test --main=Test Test.java && ./Test
[...]
Interning 16380th String
Interning 16381th String
Interning 16382th String
Interning 16383th String
Interning 16384th String
[hangs infintely]
See also some analysis at the URL above. Also present in 3.3.
--
Summary: hang when rapidly calling String.intern()
Product: gcc
Version: 3.4.4
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: debian-gcc at lists dot debian dot org
CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu
dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21703
[Bug libfortran/20436] [4.0 only] using nested reshape functions gives runtime error
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-21 19:57 --- Subject: Bug 20436 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-05-21 19:56:44 Modified files: libgfortran/generated: reshape_c4.c reshape_c8.c reshape_i4.c reshape_i8.c libgfortran/intrinsics: reshape_generic.c libgfortran/m4 : reshape.m4 libgfortran: ChangeLog gcc/testsuite : ChangeLog Log message: 005-05-21 Thomas Koenig <[EMAIL PROTECTED]> PR libfortran/20074 PR libfortran/20436 PR libfortran/21108 * m4/reshape.m4 (reshape_`'rtype_kind): rs, rex: New variables, to be used in calculation of return array sizes. Populate return array descriptor if ret->data is NULL. Fix condition for early return (it used to test something undefined if order was used). Remove duplicate check wether pad is used. * intrinsics/reshape_generic.c (reshape_generic): Likewise. Fix a few places where the wrong variables were set. * generated/reshape_i4.c: Regenerated. * generated/reshape_i8.c: Regenerated. 2005-05-21 Thomas Koenig <[EMAIL PROTECTED]> PR libfortran/20074 PR libfortran/20436 PR libfortran/21108 * gfortran.dg/nested_reshape.f90: new test * gfortran.dg/reshape-alloc.f90: new test * gfortran.dg/reshape.f90: new test Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/generated/reshape_c4.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.1.2.1&r2=1.1.2.2 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/generated/reshape_c8.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.1.2.1&r2=1.1.2.2 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/generated/reshape_i4.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.5&r2=1.5.12.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/generated/reshape_i8.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.5&r2=1.5.12.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/intrinsics/reshape_generic.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.6&r2=1.6.12.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/m4/reshape.m4.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.6.12.1&r2=1.6.12.2 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.163.2.35&r2=1.163.2.36 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.5084.2.192&r2=1.5084.2.193 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20436
[Bug libfortran/21108] [4.0 only] reshape with order causes random results
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-21 19:57 --- Subject: Bug 21108 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-05-21 19:56:44 Modified files: libgfortran/generated: reshape_c4.c reshape_c8.c reshape_i4.c reshape_i8.c libgfortran/intrinsics: reshape_generic.c libgfortran/m4 : reshape.m4 libgfortran: ChangeLog gcc/testsuite : ChangeLog Log message: 005-05-21 Thomas Koenig <[EMAIL PROTECTED]> PR libfortran/20074 PR libfortran/20436 PR libfortran/21108 * m4/reshape.m4 (reshape_`'rtype_kind): rs, rex: New variables, to be used in calculation of return array sizes. Populate return array descriptor if ret->data is NULL. Fix condition for early return (it used to test something undefined if order was used). Remove duplicate check wether pad is used. * intrinsics/reshape_generic.c (reshape_generic): Likewise. Fix a few places where the wrong variables were set. * generated/reshape_i4.c: Regenerated. * generated/reshape_i8.c: Regenerated. 2005-05-21 Thomas Koenig <[EMAIL PROTECTED]> PR libfortran/20074 PR libfortran/20436 PR libfortran/21108 * gfortran.dg/nested_reshape.f90: new test * gfortran.dg/reshape-alloc.f90: new test * gfortran.dg/reshape.f90: new test Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/generated/reshape_c4.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.1.2.1&r2=1.1.2.2 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/generated/reshape_c8.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.1.2.1&r2=1.1.2.2 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/generated/reshape_i4.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.5&r2=1.5.12.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/generated/reshape_i8.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.5&r2=1.5.12.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/intrinsics/reshape_generic.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.6&r2=1.6.12.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/m4/reshape.m4.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.6.12.1&r2=1.6.12.2 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.163.2.35&r2=1.163.2.36 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.5084.2.192&r2=1.5084.2.193 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21108
[Bug libfortran/20074] [4.0 only] reshape of pointer array segfaults at runtime
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-21 19:57 --- Subject: Bug 20074 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-05-21 19:56:44 Modified files: libgfortran/generated: reshape_c4.c reshape_c8.c reshape_i4.c reshape_i8.c libgfortran/intrinsics: reshape_generic.c libgfortran/m4 : reshape.m4 libgfortran: ChangeLog gcc/testsuite : ChangeLog Log message: 005-05-21 Thomas Koenig <[EMAIL PROTECTED]> PR libfortran/20074 PR libfortran/20436 PR libfortran/21108 * m4/reshape.m4 (reshape_`'rtype_kind): rs, rex: New variables, to be used in calculation of return array sizes. Populate return array descriptor if ret->data is NULL. Fix condition for early return (it used to test something undefined if order was used). Remove duplicate check wether pad is used. * intrinsics/reshape_generic.c (reshape_generic): Likewise. Fix a few places where the wrong variables were set. * generated/reshape_i4.c: Regenerated. * generated/reshape_i8.c: Regenerated. 2005-05-21 Thomas Koenig <[EMAIL PROTECTED]> PR libfortran/20074 PR libfortran/20436 PR libfortran/21108 * gfortran.dg/nested_reshape.f90: new test * gfortran.dg/reshape-alloc.f90: new test * gfortran.dg/reshape.f90: new test Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/generated/reshape_c4.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.1.2.1&r2=1.1.2.2 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/generated/reshape_c8.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.1.2.1&r2=1.1.2.2 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/generated/reshape_i4.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.5&r2=1.5.12.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/generated/reshape_i8.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.5&r2=1.5.12.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/intrinsics/reshape_generic.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.6&r2=1.6.12.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/m4/reshape.m4.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.6.12.1&r2=1.6.12.2 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.163.2.35&r2=1.163.2.36 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.5084.2.192&r2=1.5084.2.193 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20074
[Bug libgcj/21703] hang when rapidly calling String.intern()
-- What|Removed |Added Component|java|libgcj http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21703
[Bug libgcj/21703] hang when rapidly calling String.intern()
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-21 20:14 --- Confirmed, looks like the intern hash table becomes full. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-05-21 20:14:33 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21703
[Bug libfortran/20074] [4.0 only] reshape of pointer array segfaults at runtime
--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-05-21 20:29 --- Fixed in 4.0. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20074
[Bug libfortran/21108] [4.0 only] reshape with order causes random results
--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-05-21 20:30 --- Fixed in 4.0. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21108
[Bug libfortran/20436] [4.0 only] using nested reshape functions gives runtime error
--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-05-21 20:31 --- Fixed in 4.0. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20436
[Bug libfortran/18495] [4.0 only] Intrinisc function SPREAD is broken
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-21 20:34 --- Subject: Bug 18495 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-05-21 20:33:58 Modified files: libgfortran: ChangeLog Log message: 2005-05-21 Thomas Koenig <[EMAIL PROTECTED]> PR libfortran/18495 Also mention PR 18495 in ChangeLog. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.163.2.36&r2=1.163.2.37 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18495
[Bug libfortran/18495] [4.0 only] Intrinisc function SPREAD is broken
--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-05-21 20:34 --- Fixed in 4.0. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18495
[Bug libfortran/19872] [4.0 only] closed and re-opened file not overwriten
--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-05-21 20:34 --- Fixed. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19872
[Bug libfortran/18495] [4.0 only] Intrinisc function SPREAD is broken
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-21 20:35 --- FIxed so lets close it. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18495
[Bug tree-optimization/21568] [4.0/4.1 regression] Casts in folding *& omitted
--- Additional Comments From schlie at comcast dot net 2005-05-21 20:48
---
(In reply to comment #4)
> (In reply to comment #3)
> > (In reply to comment #1)
> > > This is undefined, see the full discussion on the gcc list:
> > > http://gcc.gnu.org/ml/gcc/2005-05/msg00073.html
> >
> > - out of curiosity, it's not clear that the discussion reached any
> >conclusion which enables GCC to disreguard the type semantics
> >as specifed by the program code. Where in the standard does it
> >specify that a type qualifier may be disreguarded if convenient?
>
> See http://gcc.gnu.org/ml/gcc/2005-05/msg00085.html
Thanks for the reference, I reviewed it and agree, but not for the reason
stated. It has nothing to do with the declared type of the object, as a
volatile qualified lvalue reference requires the object be accessed as
a volatile, but may be fully optimized away iff it can be "deduced" that
its omission would have no effect on the program's behavior.
This was only reasonable to "deduce" because the objects address was not
itself a literal address, or assigned to a volatile reference either directly or
indirectly through a potential alias (as doing so would have extended the
visibility of the object beyond the program itself, thereby requiring that the
specified volatile access semantics be retained).
In other words, in the following program variants, the specified volatile
access could not have been optimized away:
---
int avail;
(volatile int *)0x0123 = &avail; // because it's value is now potentially
// modifiable external to the program.
int main() {
while (*(volatile int *)&avail == 0)
continue;
return 0;
}
---
int *avail = (int *)0x0ABC; // as above, it's allocated location isn't
private.
int main() {
while (*(volatile int *)avail == 0)
continue;
return 0;
}
---
Thanks, If this is what GCC formally does, it would be nice to see it
documented?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21568
[Bug bootstrap/21704] New: failure during building 64-bit native compiler by crosscompiler.
sparc64-pld-linux-gcc == 32-bit sparc crosscompiler for sparc64 target. during building native 64-bit compiler I get: (...) sparc64-pld-linux-gcc -c -O2 -mcpu=ultrasparc -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wold-style-definition-DHAVE_CONFIG_H -I. -I. -I../../gcc -I../../gcc/. -I../../gcc/../include -I../../gcc/../libcpp/include \ ../../gcc/config/host-linux.c ../../gcc/config/host-linux.c: In function 'linux_gt_pch_use_address': ../../gcc/config/host-linux.c:202: error: 'SSIZE_MAX' undeclared (first use in this function) ../../gcc/config/host-linux.c:202: error: (Each undeclared identifier is reported only once ../../gcc/config/host-linux.c:202: error: for each function it appears in.) make[1]: *** [host-linux.o] Error 1 quick fix for gcc-4.0-20050514: --- gcc-4.0-snap/gcc/config/host-linux.c 2005-02-17 22:41:33.0 + +++ gcc-4.0-snap/gcc/config/host-linux.c 2005-05-21 20:49:06.0 + @@ -24,6 +24,7 @@ #include #include "hosthooks.h" #include "hosthooks-def.h" +#include -- Summary: failure during building 64-bit native compiler by crosscompiler. Product: gcc Version: 4.0.1 Status: UNCONFIRMED Severity: normal Priority: P2 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pluto at agmk dot net CC: gcc-bugs at gcc dot gnu dot org GCC target triplet: sparc64 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21704
[Bug bootstrap/21704] failure during building 64-bit native compiler by crosscompiler.
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-21 21:15 --- Can you try to include limits.h instead? -- What|Removed |Added GCC build triplet||sparc64-linux GCC host triplet||sparc-linux GCC target triplet|sparc64 |sparc64-linux Keywords||build http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21704
[Bug rtl-optimization/21402] wrong-code with inlining and type-punned pointer
--- Additional Comments From schlie at comcast dot net 2005-05-21 21:28 --- (In reply to comment #4) > Subject: Re: wrong-code with inlining and type-punned pointer > Because this is what the standard says is allowed. The standard also > says the comparisons and assignment between pointers without a case is > invalid code and should be diagnostic. Again this is what the standard > says for these things and GCC follows the C standard. Here's an interesting portion of the standard, which seems to direcly imply that signed and unsigned lvalue references are presumed to validly alias; so so this should place both in the same alias set, and potentially eliminate the default warning when comparing pointers which differ only in signness, as it seems a little silly if they may factually alias each other: 6.3 Expressions [#7] An object shall have its stored value accessed only by an lvalue expression that has one of the following types:59 - a type compatible with the effective type of the object, - a qualified version of a type compatible with the effective type of the object, - a type that is the signed or unsigned type corresponding to the effective type of the object, - a type that is the signed or unsigned type corresponding to a qualified version of the effective __ 59. The intent of this list is to specify those circumstances in which an object may or may not be aliased. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21402
Re: [Bug rtl-optimization/21402] wrong-code with inlining and type-punned pointer
"schlie at comcast dot net" <[EMAIL PROTECTED]> writes: | (In reply to comment #4) | > Subject: Re: wrong-code with inlining and type-punned pointer | > Because this is what the standard says is allowed. The standard also | > says the comparisons and assignment between pointers without a case is | > invalid code and should be diagnostic. Again this is what the standard | > says for these things and GCC follows the C standard. | | Here's an interesting portion of the standard, which seems to direcly imply | that signed and unsigned lvalue references are presumed to validly alias; so | so this should place both in the same alias set, and potentially eliminate the | default warning when comparing pointers which differ only in signness, as Sorry, I don't see that implication. However, GCC already has a switch for tuning off such comparison. -- Gaby
[Bug rtl-optimization/21402] wrong-code with inlining and type-punned pointer
--- Additional Comments From gdr at integrable-solutions dot net 2005-05-21 21:42 --- Subject: Re: wrong-code with inlining and type-punned pointer "schlie at comcast dot net" <[EMAIL PROTECTED]> writes: | (In reply to comment #4) | > Subject: Re: wrong-code with inlining and type-punned pointer | > Because this is what the standard says is allowed. The standard also | > says the comparisons and assignment between pointers without a case is | > invalid code and should be diagnostic. Again this is what the standard | > says for these things and GCC follows the C standard. | | Here's an interesting portion of the standard, which seems to direcly imply | that signed and unsigned lvalue references are presumed to validly alias; so | so this should place both in the same alias set, and potentially eliminate the | default warning when comparing pointers which differ only in signness, as Sorry, I don't see that implication. However, GCC already has a switch for tuning off such comparison. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21402
[Bug bootstrap/21704] failure during building 64-bit native compiler by crosscompiler.
--- Additional Comments From pluto at agmk dot net 2005-05-21 21:50 --- (In reply to comment #1) > Can you try to include limits.h instead? #include helps too. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21704
[Bug rtl-optimization/21402] wrong-code with inlining and type-punned pointer
--- Additional Comments From schlie at comcast dot net 2005-05-21 22:28 --- (In reply to comment #6) > Subject: Re: wrong-code with inlining and type-punned pointer > > Sorry, I don't see that implication. However, GCC already has a > switch for tuning off such comparison. - Then what is the purpose of the this portion of the standard, if not to clarify the intent that lvalues which only differ in signness or otherwise compatible qualifications may validly alias each other? (this is an honest question, I'm not trying to be difficult) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21402
Re: [Bug rtl-optimization/21402] wrong-code with inlining and type-punned pointer
On May 21, 2005, at 6:28 PM, schlie at comcast dot net wrote: --- Additional Comments From schlie at comcast dot net 2005-05-21 22:28 --- (In reply to comment #6) Subject: Re: wrong-code with inlining and type-punned pointer Sorry, I don't see that implication. However, GCC already has a switch for tuning off such comparison. - Then what is the purpose of the this portion of the standard, if not to clarify the intent that lvalues which only differ in signness or otherwise compatible qualifications may validly alias each other? (this is an honest question, I'm not trying to be difficult) unsigned and signed types are already in the same aliasing set. Just their pointers are in different aliasing set as allowed by the standard and this is where the problem is in the code in this bug. Thanks, Andrew Pinski
[Bug rtl-optimization/21402] wrong-code with inlining and type-punned pointer
--- Additional Comments From pinskia at physics dot uc dot edu 2005-05-21 22:32 --- Subject: Re: wrong-code with inlining and type-punned pointer On May 21, 2005, at 6:28 PM, schlie at comcast dot net wrote: > > --- Additional Comments From schlie at comcast dot net 2005-05-21 > 22:28 --- > (In reply to comment #6) >> Subject: Re: wrong-code with inlining and type-punned pointer >> >> Sorry, I don't see that implication. However, GCC already has a >> switch for tuning off such comparison. > > - Then what is the purpose of the this portion of the standard, if >not to clarify the intent that lvalues which only differ in signness >or otherwise compatible qualifications may validly alias each other? > > (this is an honest question, I'm not trying to be difficult) unsigned and signed types are already in the same aliasing set. Just their pointers are in different aliasing set as allowed by the standard and this is where the problem is in the code in this bug. Thanks, Andrew Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21402
[Bug web/21679] Download > Releases doesn't take me to appropriate info
--- Additional Comments From gerald at pfeifer dot com 2005-05-21 23:24 --- I installed a patch which makes "Download" a section of its own on the "Releases" page and directly link to that section from the navigation bar. (This will take up to 24 hours to become active on the production server.) If this is not sufficient, we could consider creating a download page of its own, though this would add yet another level of indirection in many cases. Having a selectable list of releases which lead to a download site for that *particular* release seems beyond what we can do with acceptable effort. We'd have to do quite some scripting and regularily check every mirror site for every release, but not all mirrors are reachable from everywhere and always. -- What|Removed |Added CC||gerald at pfeifer dot com AssignedTo|unassigned at gcc dot gnu |gerald at pfeifer dot com |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-05-21 23:24:13 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21679
[Bug libstdc++/13943] call of overloaded `llabs(int)' is ambiguous
--- Additional Comments From g_bugz at zewt dot org 2005-05-21 23:26 --- (Awesome. I spend ten minutes typing out a response, the tracker goes "you can't do that!", and I lose it all. Only Debian gets their tracker right ...) (Very old response, since the fact that this was closed was just forwarded to me through Debian earlier today.) I believe the merge with 13924 was in error; it talks about partial definitions, which is unrelated to this problem (which does not go away if is also included). In this test case, abs() and labs() work fine; only llabs() (and, I think, other C99 math functions, eg. lldiv) fails. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13943
[Bug rtl-optimization/21402] wrong-code with inlining and type-punned pointer
--- Additional Comments From schlie at comcast dot net 2005-05-21 23:31 --- (In reply to comment #8) > Subject: Re: wrong-code with inlining and type-punned pointer > > - Then what is the purpose of the this portion of the standard, if > >not to clarify the intent that lvalues which only differ in signness > >or otherwise compatible qualifications may validly alias each other? > > > > (this is an honest question, I'm not trying to be difficult) > > unsigned and signed types are already in the same aliasing set. > Just their pointers are in different aliasing set as allowed by the > standard and this is where the problem is in the code in this bug. - Thank you, although have to confess that it still eludes me how it's logically consistent that an object may be aliased through two different pointers which differ only in the signness of the objects they are specified to reverence, yet can't themselves be aliased by two different pointers which only differ in the signness of the of the dereferenced type they point to (since it would seem if X may be aliased by either *A or *B, and that *A' may alias A, and *B' may alias B; Then is seems to naturally follow that **A' and **B' may both correspondingly alias X; therefore it would seem A and B must also be considered to be in the same alias set, as otherwise the alias analysis fails to recognize this valid possibility, which is the reason the code seems to be miss-compiled)? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21402
[Bug libstdc++/13943] call of overloaded `llabs(int)' is ambiguous
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-21 23:34 --- Reopening for now. -- What|Removed |Added Status|RESOLVED|REOPENED Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13943
[Bug libstdc++/13943] call of overloaded `llabs(int)' is ambiguous
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-21 23:35 --- (In reply to comment #1) > Confirmed, most likely what needs to happen is to add a check to libstdc++'s > configure for llabs. This again should happen. -- What|Removed |Added Status|REOPENED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13943
[Bug libgcj/21703] hang when rapidly calling String.intern()
--- Additional Comments From tromey at gcc dot gnu dot org 2005-05-21 23:48 --- Testing a patch. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tromey at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21703
[Bug libgcj/21703] hang when rapidly calling String.intern()
--- Additional Comments From tromey at gcc dot gnu dot org 2005-05-21 23:56 --- In the upstream PR, a real deadlock is mentioned. The backtrace shows the finalizer thread blocking. Probably what is happening is that one thread is spinning while looking for an empty slot in the string hash table, and then the GC tries to finalize one of these strings. The String finalizer tries to acquire the lock already held by the thread looking for an empty slot, resulting in deadlock. This is just a theory, I would need at least backtraces of all the threads to be sure. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21703
[Bug libgcj/21703] hang when rapidly calling String.intern()
--- Additional Comments From tromey at gcc dot gnu dot org 2005-05-22 00:37 --- One more note -- the test case will loop infinitely even when the intern() bug has been fixed, since every 'char' value is <= \u -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21703
[Bug libgcj/21703] hang when rapidly calling String.intern()
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-22 01:04 --- Subject: Bug 21703 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-05-22 01:04:47 Modified files: libjava: ChangeLog libjava/java/lang: natString.cc libjava/java/lang/ref: natReference.cc Log message: PR libgcj/21703: * java/lang/ref/natReference.cc (find_slot): Handle case where table has no NULL entries. * java/lang/natString.cc (_Jv_StringFindSlot): Handle case where table has no NULL entries. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.3391.2.74&r2=1.3391.2.75 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/java/lang/natString.cc.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.36&r2=1.36.12.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/java/lang/ref/natReference.cc.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.6&r2=1.6.72.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21703
[Bug libgcj/21703] hang when rapidly calling String.intern()
--- Additional Comments From tromey at gcc dot gnu dot org 2005-05-22 01:06 --- I've checked in a patch on the 4.0 branch. I will put it on the trunk when it emerges from its current slushy state; I am leaving the PR open until then. I'm not planning to put this on the 3.4 branch, but if someone is motivated I think they are free to do so. -- What|Removed |Added Target Milestone|--- |4.0.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21703
[Bug java/21697] gcj segfaults with Jabref.jar
--- Additional Comments From tromey at gcc dot gnu dot org 2005-05-22 01:13 --- The jar file is actually missing the files that gcj says it cannot find. And, these classes are definitely referred to by other classes in the jar. So, that is a problem with the jar file, at least for the C++ ABI. (Compiling with -findirect-dispatch works fine.) I think there are still two bugs here: 1. We shouldn't ICE in this situation. 2. The error messages here are bogus. E.g., why is HashMap.java mentioned at all? -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-05-22 01:13:35 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21697
[Bug tree-optimization/21705] New: FRE does not catch eliminate a redundant pute call.
Consider:
extern unsigned int strlen (const char *) __attribute__ ((__pure__));
void
foo (const char *str)
{
unsigned int a = strlen (str);
unsigned int b = strlen (str);
if (a != b)
link_error ();
}
FRE does not eliminate the second call to strlen.
--
Summary: FRE does not catch eliminate a redundant pute call.
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kazu at cs dot umass dot edu
CC: dberlin at gcc dot gnu dot org,gcc-bugs at gcc dot gnu
dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21705
[Bug web/21679] Download > Releases doesn't take me to appropriate info
--- Additional Comments From dave at boost-consulting dot com 2005-05-22 03:11 --- Subject: Re: Download > Releases doesn't take me to appropriate info "gerald at pfeifer dot com" <[EMAIL PROTECTED]> writes: > --- Additional Comments From gerald at pfeifer dot com 2005-05-21 23:24 > --- > I installed a patch which makes "Download" a section of its own on the > "Releases" page and directly link to that section from the navigation bar. > > (This will take up to 24 hours to become active on the production server.) > > If this is not sufficient, we could consider creating a download page of > its own, though this would add yet another level of indirection in many > cases. > > Having a selectable list of releases which lead to a download site for > that *particular* release seems beyond what we can do with acceptable > effort. We'd have to do quite some scripting and regularily check every > mirror site for every release, but not all mirrors are reachable from > everywhere and always. I'm not advocating that, neccessarily. However, when a table of linked release names dominates the downloads page and *doesn't* lead to downloadable releases, then there's a major usability problem. It might be enough to eliminate or de-emphasize the table. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21679
[Bug tree-optimization/21705] FRE does not catch eliminate a redundant pute call.
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-22 05:27 --- Confirmed. -- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-05-22 05:27:18 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21705
